Fortran Vs C, C++, C#
in [Fortran]
|
Prev: practice online trading. platinum online trading. online trading worldwide. online trading which is best
Next: variant data type
From: Lynn McGuire on 30 Jun 2010 13:06 > Also, graphical CPUs (GPUs) have been demonstrably been getting faster--much > faster. The latest AMD and NVidia GPUs are surpassing the teraflop barrier. > You may have been ignoring graphics number-crunching when you wrote your > statement, but that's where the big money is being focused (CGI and video > games). I have been following CUDA ( http://developer.nvidia.com/page/home.html ) / OpenCL ( http://www.khronos.org/opencl/ ) with high interest. I have noted that neither have a fortran interface though. Lynn
From: Dan Nagle on 30 Jun 2010 15:25 Hello, On 2010-06-30 13:06:29 -0400, Lynn McGuire <lmc(a)winsim.com> said: > > I have been following CUDA ( http://developer.nvidia.com/page/home.html ) > / OpenCL ( http://www.khronos.org/opencl/ ) with high interest. I have > noted that neither have a fortran interface though. Since they have C interfaces, they have Fortran interfaces. Interoperability with C is widely implemented. The interesting part is the changing chips means changing semantics part of programming them. -- Cheers! Dan Nagle
From: Tim Prince on 30 Jun 2010 18:33 On 6/30/2010 3:25 PM, Dan Nagle wrote: > Hello, > > On 2010-06-30 13:06:29 -0400, Lynn McGuire <lmc(a)winsim.com> said: >> >> I have been following CUDA ( http://developer.nvidia.com/page/home.html ) >> / OpenCL ( http://www.khronos.org/opencl/ ) with high interest. I have >> noted that neither have a fortran interface though. > > Since they have C interfaces, they have Fortran interfaces. > Interoperability with C is widely implemented. > > The interesting part is the changing chips means changing semantics > part of programming them. > Successful use of nvcc via iso_c_binding as well as via PGI cudafortran has been reported. cudafortran falls short of full OpenMP functionality, in the versions I've seen, but still this hardly deserves the accusation of "no Fortran interface." A lot of developer time is being devoted by multiple vendors in this area. -- Tim Prince
From: Dan Nagle on 30 Jun 2010 18:40 Hello, On 2010-06-30 18:33:16 -0400, Tim Prince <tprince(a)myrealbox.com> said: > A lot of developer time is being devoted by multiple vendors in this area. Agreed. And a lot of standards committee's time as well. J3 is spending a lot of time on "Further Interoperability with C" and is working with the MPI Fortran binding subgroup. The level of cooperation is excellent. I expect the results to be implemented rather quickly when published. -- Cheers! Dan Nagle
From: robin on 30 Jun 2010 21:15
"Lynn McGuire" <lmc(a)winsim.com> wrote in message news:i0ft8s$qjn$1(a)news.eternal-september.org... | >> If the old Prime computers had a C compiler, it was probably | >> written in Fortran. The whole operating system was written in | >> a heavily extended fortran 66 until the 198? release which was | >> rewritten in PL/1. | > | > It did have a C compiler whose principal merit was that porting | > to it was a thorough test of the quality of your code. Integers | > were 32 bits; pointers to integers were 32 bits; pointers to | > character arrays were 48 bits. There were quite a few | > eccentricities. | | 48 bit char pointer and 32 bit integer pointer, nasty ! | | When we ported our fortran to the IBM mainframe from the Univac 1108 | in 1975, we ran into a major problem. All of the machines that we | had supported to that date were 36 bits or more using 6 bit bytes. | So, our hollerith had 6HABCDEF all over the place. We had to | change that to 4HABCD plus 2HEF. It was a major effort to change. That's because the code wasn't written with portability in mind. |