does a safer language mean it is slower to run?

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

Re: does a safer language mean it is slower to run?

[Niklas Holsti]

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.

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.

Re: does a safer language mean it is slower to run?

[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

Re: does a safer language mean it is slower to run?

[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

Re: does a safer language mean it is slower to run?

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

Re: does a safer language mean it is slower to run?

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

Re: does a safer language mean it is slower to run?

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

Re: does a safer language mean it is slower to run?

[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

Re: does a safer language mean it is slower to run?

[Shark8]

On Wednesday, June 7, 2023 at 9:55:55 PM UTC-6, 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? 
> 
> --Nasser

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.

Re: does a safer language mean it is slower to run?

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

Re: does a safer language mean it is slower to run?

[Niklas Holsti]

On 2023-10-25 20:01, robin vowels wrote:
> 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.


/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.

Re: does a safer language mean it is slower to run?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:kpt5bvFifdfU1@mid.individual.net...
> On 2023-10-25 20:01, robin vowels wrote:
>> 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.
>
>
> /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.

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.