Re: "A diagram of C23 basic types"

On Sun, 29 Jun 2025 04:44:47 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2025-06-26, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 26/06/2025 10:01, Lawrence D'Oliveiro wrote: 

C
no longer offers a great performance advantage over a higher-level
language, so you might as well use the higher-level language. 

>
Nothing is stopping you, but then comp.lang.c no longer offers
you the facility to discuss your chosen language, so you might as
well use the higher-level language's group. 

 
Even a broken clock is right once or twice in a 24h period.
 
He did say that this advantage was in the manipulation
of multi-precision integers, like big decimals.
 
Indeed, most of the time is spent int the math routines themselves,
not in what dispatches them, Calculations written in C, using a
certain bignum libarary won't be much faster than the same
calculations in a higher level language, using the same bignum
library.
>

I did few "native" python vs python+GMP vs C+GMP multiplication
measurement ~6 months ago.
See <20241225110505.00001733@yahoo.com> and followup
The end result is that python always loses to C+GMP by significant
margin except for case of python+GMP combo with absolutely huge
numbers, much bigger ones than I would ever expect to use outside
of benchmarks, where it comes close.
"Native" python loses especially badly at bigger numbers because of
less sophisticated algorithms.
Python+GMP loses especially badly at smaller numbers. I do not know an
exact reason, but would guess that it's somehow related to differences
in memory management between python and GMP.

A higher level language may also have a compiler which does
optimizations on the bignum code, such as CSE and constant folding,
basically treating it the same like fixnum integers.
 
C code consisting of calls into a bignum library will not be
aggressively optimized. If you wastefully perform a calculation
with constants that could be done at compile time, it almost
certainly won't be.
 
Example:
 
1> (compile-toplevel '(expt 2 150)) 
#<sys:vm-desc: a103620>
2> (disassemble *1) 
data:
    0: 1427247692705959881058285969449495136382746624
syms:
code:
    0: 10000400 end d0
instruction count:
    1
#<sys:vm-desc: a103620>
 
The compiled code just retrieves the bignum integer result from
static data register d0. This is just from the compiler finding
"expt" to be in a list of functions that are reducible at compile
time over constant inputs; no special reasoning about large integers.
 
But if you were to write the C code to initialize a bignum from 5,
and one from 150, and then call the bignum exponentiation routine, I
doubt you'd get the compiler to optimize all that away.
 
Maybe with a sufficiently advanced link-time optimization ...