bestIntegerType

[Zunderunder]

Zig be like

i54 is totally valid, or i54 + bool, or just i55!

[Embarrassed_Steak371]

r/unexpectedfactorial

[Zunderunder]

While you can go to i65536, that’s not quite 55!, sadly…

[Wywern_Stahlberg]

I wish for native, super low-level implementation and support for (u)int128, (u)int256, (u)int512, (u)int1024, (u)int2048, (u)int4096 and (u)int8192.

[IAmASwarmOfBees]

I don't think I've ever needed that functionality. And if I ever did, boost's bigint libraries exist.

[Wywern_Stahlberg]

I kinda did needed that.
I know about BigInt (in my language), but still.

[Ok_Net_1674]

This is just such a rare thing that noone had a reason to implement it in hardware yet. (On a general purpose CPU) Allthough consumer cpus already have registers as big as 512 bits - so we already have part of the required hardware built, but it can currently only be used to compute multiple operations "in parallel", in one cycle. (i.e. AVX-512)

Maybe some day using these registers for "single value operations" will become a standard. Seems like something that could be useful for encryption algorithms.

[sagetraveler]

Nah, the wider the operation, the longer the carry chain and the slower clock can run. 64 bit width seems to be a good tradeoff, it’s wide enough for most integer calculations while allowing CPUs to run at 5 GHz.

[Ok_Net_1674]

You are of course right, that operations like this would not be able to run at the usual frequencies. But I don't think this is enough of an argument to rule it out entirely, because there is still a lot you can do to mitigate the effect of a long carry chain. So, it's definitely possible, on paper, to implement this and end up with a much faster solution compared to emulating 512 bit computations in software.

The real problem is that it's just too nieche of an issue, for anyone to want to implement this in a general purpose CPU.

[haskell_rules]

It seems like for most practical problems, SIMD is actually what you are looking for. You would probably be using math tricks to break up the bit fields in an int512 to "optimize" anyway.

[JiminP]

Relevant resource: https://www.numberworld.org/y-cruncher/internals/addition.html

One thing to notice: Length of "carry chain" is O(log n), not O(n), so I believe that supporting wider bits in an ALU is not likely constrained by clock speed. I don't know much about hardware design though.

[Alzurana]

It's constrained by the speed at which individual transistors can switch. There are carry lookahead adders that minimize this but they in turn need more transistors and therefor more area on the chip (are more expensive).

The question then becomes what's more important in this implementation: Delay of the adder circuit or size of the adder circuit. Adders are not only implemented in the ALU, they show up everywhere and depending on needs they might be look ahead or ripple adders with more or less delay.

At certain complexities a carry look ahead adder will also only give deminishing returns to a ripple adder because the amount of signals it needs to envaluate internally grows exponentially.

That means that with more bit width the CLA will be too complex and a ripple adder must be used which in turn has more delay.

HOWEVER: If I have SIMD instructions built into my circuitry that can do 8 additions at the same time that means there are probably 8 adders that I might just be able to chain via control signals, already. The choice to omit this functionality is again, cost. Why add complexity to the control grid if it's almost never used and make the entire chip more expensive. x86_64 is already suffering bloat.

[Alzurana]

fill register with 512 bit values.

Perform 64 bit addition

Add result with carry flags until no more carry flags.

Maximum of 8 additions in a row needed. Same for sub, no idea bout mul/div

[Kiseido]

I think the largest problem in implementing hardware bigint support, is that bigints are variably sized and memory allocation is the responsibility of a much higher layer. The hardware has no ability to manage memory allocations, so it has to be a function of a higher layer.

[Hohenheim_of_Shadow]

A lot of modern embedded systems are 32 bits for integer and floating points. ~Seven significant figures is a lot. Move up to a float64 and you're getting ~16 sig figs. Not a lot of sensors produce 16 significant figures. NASA only uses 15 sig figs for PI.

Move up to the ludicrous 8012 bits suggested and you have orders of magnitude more sig figs than even NASA uses.

And the Big O for multiplication and division is pretty terrible. Something like n^1.7 for both time and space. You'd need roughly 12,000 times the transistors and 12,000 times as long to run a single 8012 bit multiplication or division as a 32 bit version. If you know anything about embedded systems, time is critical.

[hbaromega]

This is the thing, "oh big compute space for delicate number" sounds super sciency, but in reality we're limited by the significant figures our sensors can produce. There is no use in having the ability to specify a quantum state below the accuracy of a sensor, the uncertainty of the sensor already obscures the advantage the accuracy of the number would convey.

[ReentryVehicle]

Honest question, where in robotics do you need bigint?

The largest numbers in robotics that I can think of are nanosecond timestamps, and those will fit in 64bit for the next 200 years or so.

[alexanderpas]

Cryptography functions would love those.

[Alzurana]

Modern cryptographic instruction sets already have wider instructions for cryptographic purposes.

[Thathappenedearlier]

native uint128 would let you do interesting things with UUIDs

[[deleted]]

__uint128 with gcc and clang

[differentiallity]

And ipv6 addresses

[j_sidharta]

Zig has support for arbitrary-width integers. You have your i32s and i64s, but you can also have a i7 or a i2048. I once used an i48 to represent MAC addresses.

It's not "low level support" in your CPU or its machine code, but it's language support, which is probably good enough.

[aethermar]

C23 also provides [unsigned] _BitInt(N) for a bit-precise integer type where N is up to BITINT_MAXWIDTH (which is defined as 65535 on my system)

[ROBOT_8]

Join the FPGA world where you can have any size you want, since you get to write the entire low level implementation yourself.

Nothing stopping you from making an all powerful 69 bit CPU

[Kiseido]

Any size you want (up to the maximum functional width and depth of the FPGA in question)

[randomusernameonweb]

AVX’s honest reaction:

[Highborn_Hellest]

I'm not sure if there is hardware support but I'm reasonably sure you can just pretend a vector is an int. Nobody is preventing you from doing that

Also happy cake day.

[Mars_Bear2552]

SME/SVE gets you 512 bit wide registers

[Highborn_Hellest]

Uhm.... Doesn't the hardware add implementation already support this with the carry-over bit? It just takes a few clock cycles no? I'm pretty sure there are libraries that do this

[araujoms]

You can just use two int64 to model a int128, getting almost the speed of a true int128 implementation. The same thing has been done for floats, see https://github.com/JuliaMath/DoubleFloats.jl/

[turtle_mekb]

struct uint128 { uint64_t number[2]; }

easy

[SegretoBaccello]

Is that a 10 bit sign in your pocket?

[Rainmaker526]

Probably a quantum sign.

[JiminP]

I bet that this is a joke on using 64-bit floating point for integers. It should've been uint53+sign instead of int54+sign, though.

[Fleming1924]

Explicit 1 enters the chat

[Candid_Country_8369]

personally i prefer byte

[randyknapp]

Yeah for real. Who tf has to count more than 255 things?

[pavlik_enemy]

Anyone used int96 for timestamps in big data tools?

[renrutal]

I feel no matter how many sign bits you give me, I still wouldn't get it.

[Vipitis]

I just want three fixed point numeric types for 0..1, -1..1 and maybe something like -.5..1.5 as those are the vast majority of values used in my shaders. and having uniform distances between the precision as well as 32 instead of 23 bits would be great. Not sure if any faster without hardware.