info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
FORTRAN is faster than C++
388 views
Skip to first unread message
Colin Paul Gloster
Jan 18, 2023, 2:24:45 PM1/18/23
to
FORTRAN is faster than C++: HTTPS://authors.Elsevier.com/a/1gRnKcPqbl4hv
Colin Paul Gloster, Comment on "Gamma-ray spectroscopy using angular
distribution of Compton scattering" [Nucl. Instr. and Meth. A 1031 (2022)
166502], 1049:167923, 2023
Colin Paul Gloster, Comment on "Gamma-ray spectroscopy using angular
distribution of Compton scattering" [Nucl. Instr. and Meth. A 1031 (2022)
166502], 1049:167923, 2023
Thomas Koenig
Jan 18, 2023, 4:39:19 PM1/18/23
to
Colin Paul Gloster <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> schrieb:
That's a message I like to hear, but unfortunately it's behind a
paywall.
Can you summarize?
paywall.
Can you summarize?
FortranFan
Jan 18, 2023, 5:08:58 PM1/18/23
to
It's actually a very brief comment letter by Gloster (Department of Physics, University of Cambria, Portugal) and as it should, it makes reference to platforms and toolkits such as Geant4, MCNPX, FLUKA for gamma-ray spectroscopy in the physics domain.
David Jones
Jan 18, 2023, 6:47:27 PM1/18/23
to
very brief list of comparisons of the type "this is faster than that".
There is no indication of what languages or computer resouces are used
for any of these comparisons. There are references for these
comparisons, so these might be followed-up. The only mention of Fortran
is in the reference to "An empirical study of FORTRAN programs" by
Knuth of 1971. Other references are rather more recent. No mention at
all of C or C++. Come comparisons involve using CPU vs GPU.
Perhaps the OP could provide some more direct reference to support the
claim to have evidence that "FORTRAN is faster than C++". Let's hope it
is a fair like-for-like comparison.
gah4
Jan 18, 2023, 11:50:11 PM1/18/23
to
On Wednesday, January 18, 2023 at 3:47:27 PM UTC-8, David Jones wrote:
(snip)
> Perhaps the OP could provide some more direct reference to support the
> claim to have evidence that "FORTRAN is faster than C++". Let's hope it
> is a fair like-for-like comparison.
Much of OOP is done with much allocating and deallocating memory.
For many years, static allocation Fortran was faster than many other
languages that use dynamic allocation. But now much Fortran does
use dynamic allocation.
Now, there is no requirement that OOP does a huge amount of allocation,
but it often does. I have not seen that a lot of OOP Fortran is done, and
it might not do as much allocation as some C++ does, though.
In any case, it is a lot the way the language is used, and not so much
the language itself.
Or, you can write slow inefficient code, in any language.
(snip)
> Perhaps the OP could provide some more direct reference to support the
> claim to have evidence that "FORTRAN is faster than C++". Let's hope it
> is a fair like-for-like comparison.
For many years, static allocation Fortran was faster than many other
languages that use dynamic allocation. But now much Fortran does
use dynamic allocation.
Now, there is no requirement that OOP does a huge amount of allocation,
but it often does. I have not seen that a lot of OOP Fortran is done, and
it might not do as much allocation as some C++ does, though.
In any case, it is a lot the way the language is used, and not so much
the language itself.
Or, you can write slow inefficient code, in any language.
Colin Paul Gloster
Jan 19, 2023, 9:32:39 AM1/19/23
to
On January 18th, 2023, David Jones wrote:
"[. . .]
[. . .] brief list of comparisons of the type "this is faster than that".
[. . .]
Perhaps the OP could provide some more direct reference to support the
claim to have evidence that "FORTRAN is faster than C++". Let's hope it
is a fair like-for-like comparison."
Dear all:
All of the codes in question simulate the same processes of physics. Of
the CPU codes of physics in question, they are all mature and only the
Geant4 code is in C++. The FORTRAN alternatives are fast. The C++
alternative is slow.
Yours faithfully,
Colin Paul Gloster
"[. . .]
[. . .] brief list of comparisons of the type "this is faster than that".
There is no indication of what languages or computer resouces are used
for any of these comparisons. There are references for these
comparisons, so these might be followed-up. [. . .]
for any of these comparisons. There are references for these
[. . .]
Perhaps the OP could provide some more direct reference to support the
claim to have evidence that "FORTRAN is faster than C++". Let's hope it
is a fair like-for-like comparison."
All of the codes in question simulate the same processes of physics. Of
the CPU codes of physics in question, they are all mature and only the
Geant4 code is in C++. The FORTRAN alternatives are fast. The C++
alternative is slow.
Yours faithfully,
Colin Paul Gloster
Thomas Koenig
Jan 29, 2023, 7:17:10 AM1/29/23
to
Walter H. <Walter...@mathemainzel.info> schrieb:
> statements are possible;
> think of pointers to member functions in C++
> such is impossible in FORTRAN and there no problems to optimize;
Uh, no. You can also have type-bound procedures since Fortran 2003,
which amount to pretty much the same thing.
Of course, you don't _have_ to use them, but they can be quite
convenient.
> On 19.01.2023 05:50, gah4 wrote:
>> In any case, it is a lot the way the language is used, and not so much
>> the language itself.
>>
>> Or, you can write slow inefficient code, in any language.
>
> true but the optimizer can do a better work the less complicated
>> In any case, it is a lot the way the language is used, and not so much
>> the language itself.
>>
>> Or, you can write slow inefficient code, in any language.
>
> statements are possible;
> think of pointers to member functions in C++
> such is impossible in FORTRAN and there no problems to optimize;
Uh, no. You can also have type-bound procedures since Fortran 2003,
which amount to pretty much the same thing.
Of course, you don't _have_ to use them, but they can be quite
convenient.
Sergey Budaev
Jan 29, 2023, 8:01:51 AM1/29/23
to
>Uh, no. You can also have type-bound procedures since Fortran 2003,
>which amount to pretty much the same thing.
>
>Of course, you don't _have_ to use them, but they can be quite
>convenient.
I guess modern Fortran has pointers, type-bound procedures, associate
>which amount to pretty much the same thing.
>
>Of course, you don't _have_ to use them, but they can be quite
>convenient.
blocks that involve pointers in the proper sense. But in Fortran they
are quite limited compared to C++. Also e.g. for gcc the same backend
serves boith C++ and Fortran. A limited F77-style code not using
modern features may allow more aggressive compiler optimization and
might be slightly faster, maybe. But you can also use restrict in C
which to some degree is a solution to aliacing. I therefore do not
expect any really big differences in most real cases.
I have an impression that ifort unlike gfortran includes a kind of
black magic that takes into account the typical ways code is written by
non-programmer engineers, as to loops etc. This may also contribute to
performance.
--
Sergey V. Budaev
Universitetet i Bergen, Institutt for biovitenskap, Teoretisk økologi,
Thomas Koenig
Jan 29, 2023, 5:39:16 PM1/29/23
to
Sergey Budaev <for...@sergey.budaev.info> schrieb:
same sort of power.
> Also e.g. for gcc the same backend
> serves boith C++ and Fortran.
With a few additions. For example, C pointers can escape. Consider
int a;
foo (&a);
printf ("%d\n",a);
a = 42;
bar ();
printf ("%d\n",a);
The compiler (and the reader) cannot assume that bar does not
change the value of a, because foo might have stashed it away in
static storage somewhere. Yes, this is a nuisance.
Gcc contains a way for Fortran to tell the middle end that pointers
can not, in fact, escape this way.
>A limited F77-style code not using
> modern features may allow more aggressive compiler optimization and
> might be slightly faster, maybe. But you can also use restrict in C
> which to some degree is a solution to aliacing.
Fortran does make it easier, especially by default.
> I therefore do not
> expect any really big differences in most real cases.
That's hard to say without benchmarks.
Passing Fortran arrays with assumed shape actually carries some
overhead, especially for small arrays. This is much clearer
and less error-prone than what C can do (especially for small,
multi-dimensional arrays), but a compiler needs inter-procedural
analysis to get rid of that overhead.
> I have an impression that ifort unlike gfortran includes a kind of
> black magic that takes into account the typical ways code is written by
> non-programmer engineers, as to loops etc. This may also contribute to
> performance.
Hm, I somehow doubt that it's magic.
>>Uh, no. You can also have type-bound procedures since Fortran 2003,
>>which amount to pretty much the same thing.
>>
>>Of course, you don't _have_ to use them, but they can be quite
>>convenient.
>
> I guess modern Fortran has pointers, type-bound procedures, associate
> blocks that involve pointers in the proper sense. But in Fortran they
> are quite limited compared to C++.
Not as ubiquitous as in C++, very probably, but they offer the
>>which amount to pretty much the same thing.
>>
>>Of course, you don't _have_ to use them, but they can be quite
>>convenient.
>
> I guess modern Fortran has pointers, type-bound procedures, associate
> blocks that involve pointers in the proper sense. But in Fortran they
> are quite limited compared to C++.
same sort of power.
> Also e.g. for gcc the same backend
> serves boith C++ and Fortran.
int a;
foo (&a);
printf ("%d\n",a);
a = 42;
bar ();
printf ("%d\n",a);
The compiler (and the reader) cannot assume that bar does not
change the value of a, because foo might have stashed it away in
static storage somewhere. Yes, this is a nuisance.
Gcc contains a way for Fortran to tell the middle end that pointers
can not, in fact, escape this way.
>A limited F77-style code not using
> modern features may allow more aggressive compiler optimization and
> might be slightly faster, maybe. But you can also use restrict in C
> which to some degree is a solution to aliacing.
> I therefore do not
> expect any really big differences in most real cases.
Passing Fortran arrays with assumed shape actually carries some
overhead, especially for small arrays. This is much clearer
and less error-prone than what C can do (especially for small,
multi-dimensional arrays), but a compiler needs inter-procedural
analysis to get rid of that overhead.
> I have an impression that ifort unlike gfortran includes a kind of
> black magic that takes into account the typical ways code is written by
> non-programmer engineers, as to loops etc. This may also contribute to
> performance.
gah4
Jan 29, 2023, 11:50:16 PM1/29/23
to
On Sunday, January 29, 2023 at 2:39:16 PM UTC-8, Thomas Koenig wrote:
(snip)
> int a;
> foo (&a);
> printf ("%d\n",a);
> a = 42;
> bar ();
> printf ("%d\n",a);
> The compiler (and the reader) cannot assume that bar does not
> change the value of a, because foo might have stashed it away in
> static storage somewhere. Yes, this is a nuisance.
But Fortran has COMMON, and now module variables, which can
change at surprising times. Maybe not as surprising as for C.
Even so, the compiler has to assume that any COMMON variable,
and many module variables, can change.
Where are the rules on when pointed-to variables can change?
With C-interoperability, one could call C programs that keep pointers.
> Gcc contains a way for Fortran to tell the middle end that pointers
> can not, in fact, escape this way.
(snip)
do have overhead. In the olden days (through Fortran 77) static allocation
allows low overhead access to arrays.
On the other hand, static sized arrays have their own overhead, especially
when they have to be sized the largest they might ever need to be.
(snip)
> int a;
> foo (&a);
> printf ("%d\n",a);
> a = 42;
> bar ();
> printf ("%d\n",a);
> The compiler (and the reader) cannot assume that bar does not
> change the value of a, because foo might have stashed it away in
> static storage somewhere. Yes, this is a nuisance.
change at surprising times. Maybe not as surprising as for C.
Even so, the compiler has to assume that any COMMON variable,
and many module variables, can change.
Where are the rules on when pointed-to variables can change?
With C-interoperability, one could call C programs that keep pointers.
> Gcc contains a way for Fortran to tell the middle end that pointers
> can not, in fact, escape this way.
> Passing Fortran arrays with assumed shape actually carries some
> overhead, especially for small arrays. This is much clearer
> and less error-prone than what C can do (especially for small,
> multi-dimensional arrays), but a compiler needs inter-procedural
> analysis to get rid of that overhead.
Dynamic allocation, and especially the complications of assumed shape,
> overhead, especially for small arrays. This is much clearer
> and less error-prone than what C can do (especially for small,
> multi-dimensional arrays), but a compiler needs inter-procedural
> analysis to get rid of that overhead.
do have overhead. In the olden days (through Fortran 77) static allocation
allows low overhead access to arrays.
On the other hand, static sized arrays have their own overhead, especially
when they have to be sized the largest they might ever need to be.
Thomas Koenig
Jan 30, 2023, 3:27:43 AM1/30/23
to
gah4 <ga...@u.washington.edu> schrieb:
> Maybe not as surprising as for C.
> Even so, the compiler has to assume that any COMMON variable,
> and many module variables, can change.
But not that they may alias with arguments.
And the problem with C is that there is no way to get an INTENT(OUT)
equivalent _without_ pointers potentially escaping, unless you do
something like
int a;
{
int b;
foo (&b);
a = b;
[...]
> On Sunday, January 29, 2023 at 2:39:16 PM UTC-8, Thomas Koenig wrote:
>
>
> (snip)
>
>> int a;
>> foo (&a);
>> printf ("%d\n",a);
>> a = 42;
>> bar ();
>> printf ("%d\n",a);
>
>> The compiler (and the reader) cannot assume that bar does not
>> change the value of a, because foo might have stashed it away in
>> static storage somewhere. Yes, this is a nuisance.
>
> But Fortran has COMMON, and now module variables, which can
> change at surprising times.
Yes.
>
>
> (snip)
>
>> int a;
>> foo (&a);
>> printf ("%d\n",a);
>> a = 42;
>> bar ();
>> printf ("%d\n",a);
>
>> The compiler (and the reader) cannot assume that bar does not
>> change the value of a, because foo might have stashed it away in
>> static storage somewhere. Yes, this is a nuisance.
>
> But Fortran has COMMON, and now module variables, which can
> change at surprising times.
> Maybe not as surprising as for C.
> Even so, the compiler has to assume that any COMMON variable,
> and many module variables, can change.
And the problem with C is that there is no way to get an INTENT(OUT)
equivalent _without_ pointers potentially escaping, unless you do
something like
int a;
{
int b;
foo (&b);
a = b;
}
printf ("%d\n",a);
a = 42;
bar ();
printf ("%d\n", a);
which is verbose, error-prone and which hardly anybody ever does.
printf ("%d\n",a);
a = 42;
bar ();
printf ("%d\n", a);
[...]
Spiros Bousbouras
Jan 30, 2023, 10:07:40 AM1/30/23
to
On Sun, 29 Jan 2023 22:39:12 -0000 (UTC)
Thomas Koenig <tko...@netcologne.de> wrote:
> With a few additions. For example, C pointers can escape. Consider
>
> int a;
> foo (&a);
> printf ("%d\n",a);
> a = 42;
> bar ();
> printf ("%d\n",a);
>
> The compiler (and the reader) cannot assume that bar does not
> change the value of a, because foo might have stashed it away in
> static storage somewhere. Yes, this is a nuisance.
If foo() has been declared as
Thomas Koenig <tko...@netcologne.de> wrote:
> With a few additions. For example, C pointers can escape. Consider
>
> int a;
> foo (&a);
> printf ("%d\n",a);
> a = 42;
> bar ();
> printf ("%d\n",a);
>
> The compiler (and the reader) cannot assume that bar does not
> change the value of a, because foo might have stashed it away in
> static storage somewhere. Yes, this is a nuisance.
whatever foo(const int *p)
then it can only copy the value of p to another const * int
pointer and you cannot change the value of a through that.
Ron Shepard
Jan 31, 2023, 1:46:24 AM1/31/23
to
On 1/29/23 10:50 PM, gah4 wrote:
> On Sunday, January 29, 2023 at 2:39:16 PM UTC-8, Thomas Koenig wrote:
>
>
> (snip)
>
> On Sunday, January 29, 2023 at 2:39:16 PM UTC-8, Thomas Koenig wrote:
>
>
> (snip)
>
>> int a;
>> foo (&a);
>> printf ("%d\n",a);
>> a = 42;
>> bar ();
>> printf ("%d\n",a);
>
>> The compiler (and the reader) cannot assume that bar does not
>> change the value of a, because foo might have stashed it away in
>> static storage somewhere. Yes, this is a nuisance.
>
>> foo (&a);
>> printf ("%d\n",a);
>> a = 42;
>> bar ();
>> printf ("%d\n",a);
>
>> The compiler (and the reader) cannot assume that bar does not
>> change the value of a, because foo might have stashed it away in
>> static storage somewhere. Yes, this is a nuisance.
>
> But Fortran has COMMON, and now module variables, which can
> change at surprising times. Maybe not as surprising as for C.
> Even so, the compiler has to assume that any COMMON variable,
> and many module variables, can change.
If the above C code were rewritten in the straightforward way in
> and many module variables, can change.
fortran, then the fortran bar() function cannot modify a. That is
because the local variable a is not a target, and it cannot be aliased
to any other subroutine argument or to anything in a module or in a
common block and then modified. Even if the function foo() were to use a
local pointer to a, it is not allowed for foo() to modify the value
through that pointer, because the actual argument is not a target (or
pointer). That is, foo() can access the value through its local pointer,
but it cannot modify that value. If bar() has access to that same
pointer, then the restrictions apply also to what a programmer is
allowed to do within bar().
Of course, a programmer can violate that constraint with trickery,
particularly when foo() and bar() are not written in fortran, but that
nonconforming code would be an error on the programmer's part, not a
feature of the fortran language as it is with C.
[...]
> Dynamic allocation, and especially the complications of assumed shape,
> do have overhead. In the olden days (through Fortran 77) static allocation
> allows low overhead access to arrays.
Now that the recursive attribute is the default, almost all local
> do have overhead. In the olden days (through Fortran 77) static allocation
> allows low overhead access to arrays.
entities must be dynamically allocated (i.e. stack or heap) when a
subprogram is entered. However, if all local variables are saved (which
means no automatic arrays are present), then it is pretty much back to
the same situation as pre-f90 code, where everything could be compiled
to static addresses. Presumably that would put the call overhead back to
similar pre-f90 levels. As you point out, there are also efficiency
downsides to that approach, e.g. the overall memory footprint is larger,
which can affect cache reuse and memory locality.
As for assumed shape arguments, the upside is that they no longer need
to be contiguous as they did for pre-f90 arrays, so that feature can
eliminate temporary copies from being required, either explicitly by the
programmer or implicitly by the compiler. Of course, there are
situations where a contiguous copy is more efficient to use, so
sometimes this new functionality is more efficient and sometimes less.
When a noncontiguous actual argument is associated with a dummy argument
that must be contiguous (e.g. explicit shape, assumed size, and so on),
then the compiler must make that copy implicitly during the call,
whether or not it is the most efficient choice.
$.02 -Ron Shepard
gah4
Feb 15, 2023, 5:30:33 PM2/15/23
to
On Wednesday, January 18, 2023 at 11:24:45 AM UTC-8, Colin Paul Gloster wrote:
> FORTRAN is faster than C++:
I decided to ask the reliable source, ChatGPT, this question:
> FORTRAN is faster than C++:
"The performance of a programming language depends on various factors, including the efficiency of the language implementation, the quality of the code, and the specific task at hand. Therefore, it is difficult to make a general statement about whether Fortran or C++ is faster.
Historically, Fortran was developed specifically for scientific and engineering computations, and it has been optimized for numerical calculations. As a result, Fortran has a long-standing reputation for being faster than many other programming languages in numerical applications. However, modern compilers for C++ have improved significantly over the years, and with careful programming and optimization, it is possible to achieve similar performance to Fortran in many cases.
Ultimately, the choice of programming language depends on various factors, including the specific task at hand, the available resources, the developer's skills and experience, and the performance requirements. It is always a good idea to benchmark the performance of different implementations and evaluate them based on the specific requirements of the project."
Gary Scott
Feb 15, 2023, 6:11:24 PM2/15/23
to
gah4
Feb 15, 2023, 6:24:01 PM2/15/23
to
On Wednesday, February 15, 2023 at 3:11:24 PM UTC-8, Gary Scott wrote:
(snip, I wrote)
> I couldn't have written it better...literally :(
It seems that teachers are worried about grading students essays.
Though I heard that ChatGPT is supposed to have a tool to help them
recognize fake essays.
I do remember students being assigned essays as a penalty, maybe for
acting out in class, or otherwise not following rules. I suspect such essays
don't have the detailed grading of class assigned essays. Maybe teachers
don't do that anymore.
(snip, I wrote)
> > I decided to ask the reliable source, ChatGPT, this question:
(snip of answer to question)
> I couldn't have written it better...literally :(
Though I heard that ChatGPT is supposed to have a tool to help them
recognize fake essays.
I do remember students being assigned essays as a penalty, maybe for
acting out in class, or otherwise not following rules. I suspect such essays
don't have the detailed grading of class assigned essays. Maybe teachers
don't do that anymore.
Dick Hendrickson
Feb 16, 2023, 12:54:11 PM2/16/23
to
and it replied "Yes."
So, maybe there's hope.
Dick Hendrickson
0 new messages