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

[Shark8 <onewingedshark@gmail.com>]

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.