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 <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> schrieb:
> 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

That's a message I like to hear, but unfortunately it's behind a
paywall.

Can you summarize?

On Wednesday, January 18, 2023 at 2:24:45 PM UTC-5, Colin Paul Gloster wrote:
> 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

The actual article makes no reference to the two languages at all. That would be insane. Comparing languages in terms of speed is mostly a meaningless exercise now.

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.

Thomas Koenig wrote:

> Colin Paul Gloster
> <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> schrieb:
> > 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
>
> That's a message I like to hear, but unfortunately it's behind a
> paywall.
>
> Can you summarize?

It's not worth seeing for itself. It is very brief and it just gives a
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.

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.

On January 18th, 2023, David Jones wrote:
"[. . .]

[. . .] 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. [. . .]
[. . .]

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

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
statements are possible;
think of pointers to member functions in C++
such is impossible in FORTRAN and there no problems to optimize;

Walter H. <Walter.H-Nntp@mathemainzel.info> schrieb:
> 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
> 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.

>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++. 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,

Sergey Budaev <fortran@sergey.budaev.info> schrieb:
>>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
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.

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)
> 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,
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.

gah4 <gah4@u.washington.edu> schrieb:
> 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.

> 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;
}
printf ("%d\n",a);
a = 42;
bar ();
printf ("%d\n", a);

which is verbose, error-prone and which hardly anybody ever does.

[...]

On Sun, 29 Jan 2023 22:39:12 -0000 (UTC)
Thomas Koenig <tkoenig@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
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.