does a safer language mean it is slower to run?

[Nasser M. Abbasi]

Some folks in this thread

https://discourse.julialang.org/t/comparison-of-rust-to-julia-for-scientific-computing/78508

"I’m not an expert, but my feeling is that Rust is a “safer” language,
which to me means it must be slower."

etc..

Some in that thread seem to argue that a safer language
will/could be slower than otherwise.

Since Ada is known to be one of the safest languages,
do others here feel there is any truth to this?

I thought that by having more type information in the language,
the compile will be able to make more optimizations (because it
know more), and hence the generated code should actually be
faster, not slower with a language that is less safe?

I am not a compiler expert but what do others here think?

--Nasser

[Niklas Holsti]

If a language needs run-time checks to ensure safety, those checks
usually take some time, making for slower execution.

If a language has a type system and compilation-time (legality) rules
such that the compiler can prove that some run-time checks are not
needed, that reduces or eliminates the slow-down. This is the case for Ada.

The effect of type information on optimization is harder (at least for
me) to understand. If the type information lets the compiler assume that
some objects are not aliased, that can help optimization because more
computation can be done in registers alone, without using main memory.
This applies to Ada, but also applies to standard C, for example,
although some people use non-standard C features (compiler options) to
negate this.

However, when comparing the "speed" of two languages and their two
implementations I think that the implementations usually matter more
than the languages.

[Dmitry A. Kazakov]

On 2023-06-08 05:55, Nasser M. Abbasi wrote:
> Some folks in this thread
>
> https://discourse.julialang.org/t/comparison-of-rust-to-julia-for-scientific-computing/78508
>
> "I’m not an expert, but my feeling is that Rust is a “safer” language,
> which to me means it must be slower."

I think comparison is misplaced. Julia is an interpreted language, very
slow, on par with Python. It has memory mapped arrays like Ada does, but
lacks Python's precompiled modules. The syntax is wonderfully arbitrary
and unpredictable...

> Some in that thread seem to argue that a safer language
> will/could be slower than otherwise.

> Since Ada is known to be one of the safest languages,
> do others here feel there is any truth to this?
>
> I thought that by having more type information in the language,
> the compile will be able to make more optimizations (because it
> know more), and hence the generated code should actually be
> faster, not slower with a language that is less safe?
>
> I am not a compiler expert but what do others here think?

If safety is prevention of logical errors (bugs) you and your team and
people deploying the software could make, then techniques and processes
determine the outcome. The language can only support certain techniques.
Of these techniques and processes some may require run-time overhead.
When people compare languages, they frequently do programming techniques
instead. As it was observed many decades ago:

"Besides, the determined Real Programmer can write Fortran programs in
any language."

And finally, if you determined to use some technique, then lack of
language support makes the language less safe. E.g. if you are in some
agile programming lager then semantic constraints imposed by Ada would
make things only worse.

Even Brainf*ck might be the safest language under circumstances... (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Jeffrey R.Carter]

On 2023-06-08 05:55, Nasser M. Abbasi wrote:
>

> Some in that thread seem to argue that a safer language
> will/could be slower than otherwise.
>
> Since Ada is known to be one of the safest languages,
> do others here feel there is any truth to this?

Equivalent programs in compiled, non-GC languages have equivalent execution
times. Robert Dewar famously had a set of equivalent Ada and C programs that
produced identical machine code when compiled with gcc. So this is false.

The problem is getting equivalent programs. If the safe language includes
run-time checks, then equivalent checks must be manually added to the unsafe
language. Ada.Text_IO is not equivalent to C's I/O facilities. And so on.

Once consequence of this is that both programs will be equally correct. What is
usually compared is a correct (run-time checks) program in the safe language to
an incorrect (no run-time checks) program in the unsafe language.

About optimization, Tartan made its living selling highly optimizing C compilers
for TI chips, which came with a free C compiler. They also made highly
optimizing Ada compilers, which did a better job of optimization than their C
compilers. This was documented in

C vs Ada: arguing performance religion
(https://dl.acm.org/doi/10.1145/216578.216583)

which discusses four advantages Ada (83) has over C for optimization.

See also

Ada Outperforms Assembly: A Case Study
(https://www2.seas.gwu.edu/~adagroup/sigada-website/lawlis.html)

TI bought Tartan and sold its Ada compilers to DDC-I.

--
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

[Luke A. Guest]

On 08/06/2023 04:55, Nasser M. Abbasi wrote:
> Some folks in this thread
>
> https://discourse.julialang.org/t/comparison-of-rust-to-julia-for-scientific-computing/78508
>
> "I’m not an expert, but my feeling is that Rust is a “safer” language,
> which to me means it must be slower."

What these idiots ^ never do is define "slow," slow compared to WHAT?
They also don't seem to realise we basically use supercomputers now,
these things are way more powerful than the 8-bit/16-bit cpu's of the
70's and 80's. This mentality has come from there where optimisation at
the assembly level to pick the faster (less clock cycles) instructions.

And they always just say "Oh, that's SLOW!" I had the same when I joined
that games company, "we don't use virtuals, because they're SLOW." No,
they might be a tad slower in clock cycles.

These people also don't do safety, they don't do checks most of the time
and just want to make stuff as "fast" as possible without doing anything
to make sure it works correctly.

[Jerry]

On Thursday, June 8, 2023 at 1:00:55 AM UTC-7, Dmitry A. Kazakov wrote:
> I think comparison is misplaced. Julia is an interpreted language, very
> slow, on par with Python. It has memory mapped arrays like Ada does, but
> lacks Python's precompiled modules. The syntax is wonderfully arbitrary
> and unpredictable...

[I guess this is OT.] Julia is a hot mess. Rather than being interpreted, it uses a just-in-time compiler, so they claim they have the solution to the "two-language problem" of prototyping in a slow language such as Python then re-writing in a compiled language for speed. There are problems. Julia has a bad habit of forgetting that it compiled a program before (no saved binary between sessions) so it has to re-compile it each time. (I think there are work-arounds but not intended for mere mortals.) Julia folks seem to have invented the phrase "time to first plot" because much of the Julia ecosystem is written in Julia so it has to go off and compile the plotters before you can make the first plot, or something like that. However, using Julia in Visual Studio Code where there is a very nice notebook Jupyter environment plus a very clever hybrid of a REPL and standard editor, is quite delightful. There is a set of officially published instructions for getting maximum speed from Julia https://docs.julialang.org/en/v1/manual/performance-tips; when printed as as PDF, it spans 36 pages and uses terminology and concepts that only an expert will know. People love Julia for its multiple-dispatch feature whereby it automatically generates a different version of a subroutine for every combination of argument and result that it can discover. (This behavior can be overridden by using ----- optional typing!) If you think dynamic typing is 180 degrees from strong typing, I would suggest that it is now only 90 degrees from strong typing, with Julia's brand new opportunities for accidentally calling a subroutine that you didn't even know existed now occupying the 180 degree position.

[Gautier write-only address]

Good to learn that there is a searchable name "two-language problem" for that issue.
Another, not-well-known, solution, is Ada (with HAC on the prototyping side, and GNAT or other full-Ada systems on the production side)...

[Kevin Chadwick]

On 08/06/2023 16:19, Luke A. Guest wrote:
>On 08/06/2023 04:55, Nasser M. Abbasi wrote:
>> Some folks in this thread
>>
>> https://discourse.julialang.org/t/comparison-of-rust-to-julia-for-scientific-computing/78508
>>
>> "I’m not an expert, but my feeling is that Rust is a “safer” language,
>> which to me means it must be slower."
>

Rust isn't a safer language. Rust is more targetted at the heap which is
slower than the stack. Additionally if you use Adas type system well then
you can remove input validation checks again making Ada faster. The
compiler is better and safer at optimising checks away.


--
Regards, Kc

[Shark8]

An interesting proposition fueled by two differing intuitions: one, saying that mandatory checks must necessarily slow things down, and the other saying that having more information allows for greater optimization.

We can, of course, walk through a few simple/trivial examples to flesh out which intuition is more correct.

FIRST, let's consider Array-access in Ada, which mandates a check on the index:

Subtype Real is Float range Float'Range; -- Removing NaN, INF, etc.
Type Real_Vector is array (Positive range <>) of Real;
Function Normalize(Input : in Real_Vector) return Real_Vector is

Function Maximum return Real is
Begin
-- Start w/ Negative-most number; geturn the maximum.
Return Result : Real:= Real'First do
For Index in Input'Range loop
Result:= Real'Max(Result, Input(Index));
end loop;
End return;
End Maximum;

Begin
case Input'Length is
when 0 => Return Input;
when 1 => Return (1 => 1.0);
when others =>
Return Result : Real_Vector(Input'Range) do
declare
Max : Real renames Maximum;
begin
For Index in Result'Range loop
Result(Index):= Input(Index) / Max;
End loop;
end;
End return;
end case;
End Normalize;

In the above, we see the control of the For-loop, "Index", which takes its values from the input (directly or indirectly), and therefore the indexing of Input(Index) *cannot* be outside the bounds of the array, Input. This means that we can omit the checks altogether as Index is bound to the constraints of the array. And we can deduce this directly from the source, at compile-time, therefore allowing us to remove the checks altogether.

SECOND, consider:

Type Window is tagged private;
Type Window_Pointer is access all Window'Class;
Subtype Window_Handle is not null Window_Pointer;

Procedure Set_Title( Object : Window_Handle; Text : String );

In the above, we see that Object is an access to Window'Class which excludes Null -- since this constraint is enforced to the parameter on-call, in the body the compiler can assume that "Object /= Null" is true.

THIRD, similar to the second:

Type Safe_Text is String
with Dynamic_Predicate => (for all Ch of Safe_Text => Ch in 'a'..'z'|'A'..'Z'|' '||'0'..'9');
Function Transform( Input : Safe_Text ) return Safe_Text;

X : Safe_Text := Transform(Transform(Transform(Transform( Whatever ))));

in the above, we note that the parameter is checked for conformance, raising exception CONSTRAINT_ERROR if it fails, and is guaranteed to either return a Safe_Text value or else raise an exception -- applying these, we can eliminate all the checks for the parameter except the innermost, thus optimizing in a way that you cannot if your input and output types were more broad.

So, the intuition that "more information provides more optimization opportunity" is the correct one.

[robin vowels]

On Thursday, 8 June 2023 at 16:57:17 UTC+10, Niklas Holsti wrote:
> On 2023-06-08 6:55, Nasser M. Abbasi wrote:
> > Some folks in this thread
> >
> > https://discourse.julialang.org/t/comparison-of-rust-to-julia-for-scientific-computing/78508
> >
> > "I’m not an expert, but my feeling is that Rust is a “safer” language,
> > which to me means it must be slower."
> >
> > etc..
> >
> > Some in that thread seem to argue that a safer language
> > will/could be slower than otherwise.
> >
> > Since Ada is known to be one of the safest languages,
> > do others here feel there is any truth to this?
> >
> > I thought that by having more type information in the language,
> > the compile will be able to make more optimizations (because it
> > know more), and hence the generated code should actually be
> > faster, not slower with a language that is less safe?
> >
> > I am not a compiler expert but what do others here think?

.

> If a language needs run-time checks to ensure safety, those checks
> usually take some time, making for slower execution.

.
Some language features need run-time checks. These checks cannot be
carried out at compile time.
.
PL/I has some features that require run-time checks. When the computer
hardware has certain facilities, that support does not take extra execution time.
For example, floating-point overflow and integer overflow are detected by the
hardware on the IBM S/360 and subsequent machines including up to the latest
System z. Such detections cause an interrupt that can be handled by the PL/I
program. On the PC, integer overflow can cause an interrupt.

.
> If a language has a type system and compilation-time (legality) rules
> such that the compiler can prove that some run-time checks are not
> needed, that reduces or eliminates the slow-down. This is the case for Ada.

.
Range is not one of them.

[Niklas Holsti]

/Some/ range checks in Ada can certainly be verified at compile time.
For example:

type ABCD is (A, B, C, D);
subtype BCD is ABCD range B .. D;

procedure Foo (X : in BCD)
is
Y : ABCD := X;
Z : ABCD := ABCD'Pred(Y);
...

The initialization of Y formally involves a range check of X, but since
BCD is a subtype of ABCD, the check can be elided at compile time.
Likewise, the initialization of Z, with its computation of the Pred,
formally includes a range check of Y, but since Y /= A can easily be
proved, that range check can also be elided.

The most important type of check that can be elided at Ada compile time
is array index check. Because arrays have specific index types in Ada,
the compiler can often prove that the index expression will be in range.

[Randy Brukardt]

"Niklas Holsti" <niklas...@tidorum.invalid> wrote in message
news:kpt5bv...@mid.individual.net...

Right. And programmers can often write their code to ensure that no range
check will be needed. The most obvious case occurs in loops:

for I in Arr'range loop
... Arr(I) ... -- Needs no range check, since I can never be outside
of the legal range of the array index.
end loop;

(Of course, the element for loop disposes with the array indexing
altogether, which is even better.)

Randy.