From: no.email@nospam.invalid   
      
   anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:   
   > If implemented well, the slowdown is small in the common case (small   
   > integers): E.g., on AMD64 an add, sub, or imul instruction just needs   
   > to be followed by a jo which in the usual case is not taken and very   
   > predictable.   
      
   It might be worse for RISC V.  Either way though, you need either boxed   
   integers or tag bits.   
      
   > Python (particularly CPython), however, does not seem to have gone for   
   > efficient implementation;   
      
   CPython's implementation is not very good, but there is or was a gmpy   
   module that let you use GMP for fast bignum arithmetic.  I remember in   
   the Python 2.2 era it was 3x or 4x faster than CPython bignums.  But, I   
   think it has since fallen into non-maintenance and bit rot.   
      
   > I don't know what they do for arbitrarily large integers, but the   
   > inner interpreter was pretty monstrous last I looked.   
      
   CPython has a fairly straightforward bytecode interpreter.   
      
   > But integer overflow is orthogonal to memory safety.   
   > There are many people who claim that wrapping behaviour for integer   
   > overflow is a problem.   
      
   It has a problem because it's wrong!  Of course it's deterministic   
   instead of being UB, and that makes some people feel better, but making   
   2+2=5 is also deterministic yet wrong.  At least with UB, the   
   implementation can have a setting to do the right thing and trap the   
   overflow, instead of being mandated to quietly give wrong results.   
      
   Imagine x is a 50 element array and for whatever reason you try to   
   update x[60].  So the implementation might clobber 10 elements past the   
   end of the array (bad), or it can signal an error (the only thing that   
   makes sense), or in a feat of Java-like brilliance it might alias x[60]   
   to x[10] since 60 is 10 mod 50.  That seems completely silly to me as a   
   default behaviour.  Integer overflow wraparound is more of the same.   
      
   Yes there are situations like circular buffers where you might want that   
   wraparound, just like there are situations like hash functions where you   
   want machine word wraparound, but those are special enough to call for   
   explicit declarations.   
      
      
   > Java defines the basic types int and long to perform wraparound on   
   > overflow,   
      
   Yes, a mistake IMHO.  The one language that I know of that gets this   
   right is Ada.  The default behavior is signal on overflow, but you can   
   specify wraparound (with any modulus you wish) if that is what your   
   application wants.  If your modulus happens to be 2**32 or whatever, the   
   compiler recognizes this and generates the efficient machine code you   
   would expect.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)