@MSGID:
<c5c09218-e170-4c16-b793-024683f21568n@googlegroups.com> 5e50eeab
@REPLY: 1@dont-email.me> 6c855399
@REPLYADDR Shark8 <onewingedshark@gmail.com>
@REPLYTO 2:5075/128 Shark8
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
@RFC-Message-ID:
<c5c09218-e170-4c16-b793-024683f21568n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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-com
puting/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.

--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441