<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Lots of checks are being dropped in hardware to allow uniprocessors running sequential programs to run fast. As it happens, we run multiprocessors, mostly running sequential programs.
<br>
</p>
<p>Premature optimization is the root of all evil -- Knuth</p>
<p>Do modern languages like Go and Rust need that particular set of optimizations?<br>
</p>
<p>--dave</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2019-06-20 11:41 a.m., D. Hugh Redelmeier via talk wrote:<br>
</div>
<blockquote type="cite" cite="mid:alpine.LFD.2.21.1906201123520.4314@redeye.mimosa.com">
<pre class="moz-quote-pre" wrap="">| From: David Mason via talk <a class="moz-txt-link-rfc2396E" href="mailto:talk@gtalug.org"><talk@gtalug.org></a>
| You can turn the checks on, but see this discussion about the default: <a class="moz-txt-link-freetext" href="https://github.com/rust-lang/rust/issues/47739">https://github.com/rust-lang/rust/issues/47739</a>
Thanks. The issue isn't "resolved" so I guess that the default has
not been changed.
One comment pointed at this which I found fascinating:
<a class="moz-txt-link-rfc2396E" href="https://capnproto.org/news/2015-03-02-security-advisory-and-integer-overflow-protection.html"><https://capnproto.org/news/2015-03-02-security-advisory-and-integer-overflow-protection.html></a>
Again, I found that being able to declare variables as being within a
range as being very powerful. I admit that the edges get messy: just
as requiring arrays to have compile-time bounds is constraining,
tight compile-time bounds on integer types is sometimes overly
constraining.
Of course what we have in most languages is compile-time bounds, but
with the hope that they are generous. And usually they are.
One could argue that if overflow is rare, we should be able to handle
it by falling over to bignums. Unfortunately that adds overhead to
every operation -- perhaps JIT compiling techniques could fix that.
Maybe a single solution doesn't fit all cases. But silently yielding
a wrong answer on overflow is just dangerous. And defining the wrong
answer to be correct is not really better.
My intuition is that range declaration and checking might actually
might be more efficient that simple overflow checking. The compiler
would have more actionable information to optimize out checks. After
all, most functions are not "partial": the result is well-defined if
the parameters conform to their constraints. It's sometimes hard to
express those constraints in the type system.</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">---
Talk Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:talk@gtalug.org">talk@gtalug.org</a>
<a class="moz-txt-link-freetext" href="https://gtalug.org/mailman/listinfo/talk">https://gtalug.org/mailman/listinfo/talk</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
<a class="moz-txt-link-abbreviated" href="mailto:dave.collier-brown@indexexchange.com">dave.collier-brown@indexexchange.com</a> | -- Mark Twain
</pre>
<br>
<p><strong><em><span style="color: #212121;">CONFIDENTIALITY NOTICE AND DISCLAIMER</span></em></strong><em><span style="color: #212121;"> : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s)
to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail
and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance
of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.</span></em></p>
</body>
</html>