Date: Mon, 31 Mar 2025 00:25:23 -0400
On Sunday, 30 March 2025 19:42:02 Eastern Daylight Time Jason McKesson via
Std-Proposals wrote:
> > Having 32-Bit int's on x86_64 is fine because the instruction set
> > accommodates them, but on another CPU architecture that deals solely
> > with 64-Bit integers, a lot of CPU cycles would be wasted
> > Bitwise-AND'ing with 0xffffffff.
>
> Which sounds like a good reason not to make such CPUs. Or to give them
> instructions that make such things not cost performance. Hardware
> design is often a complex dance between what the hardware vendors
> would like and what users can tolerate. If your new CPU is 10% slower
> for no good reason, people won't buy it.
Right, there's simply no way such a CPU would find mainstream adoption. Some
niche DSP might, but even then I doubt it. 32-bit integers are just do damn
useful; any CPU or microcontroller is likely going to have support for the
type. And if they do, the C language psABI is likely going to bind int to that
hardware type.
Moreover, I think Frederick is incorrectly reading the tea leaves here. The
move from 16- to 32- and thence to 64-bit wasn't driven by the need for larger
integers, but by the need for larger pointers. And we don't have a need for
larger pointers anywhere near the horizon. Nothing above 32 TB of RAM and 8
sockets of processors is commonplace. I know bigger machines exist, but there
must be at most tens of them in the world. That means around 128 TB (2^47
bytes) is the current maximum requirement, which is a full 3 orders of
magnitude away from the x86-64 theoretical limit for virtual address space.
In fact, the current trend is the other way around: break up the single, large
machine into many smaller ones that can work in a cluster. Further, because of
the memory requirements, we are seeing far more need for *smaller* data types,
not bigger. For example, I see a far greater need for instructions for 8-bit
multiplication with 16-bit accumulators than I see for 128-bit multiplication
with 256-bit results.
Std-Proposals wrote:
> > Having 32-Bit int's on x86_64 is fine because the instruction set
> > accommodates them, but on another CPU architecture that deals solely
> > with 64-Bit integers, a lot of CPU cycles would be wasted
> > Bitwise-AND'ing with 0xffffffff.
>
> Which sounds like a good reason not to make such CPUs. Or to give them
> instructions that make such things not cost performance. Hardware
> design is often a complex dance between what the hardware vendors
> would like and what users can tolerate. If your new CPU is 10% slower
> for no good reason, people won't buy it.
Right, there's simply no way such a CPU would find mainstream adoption. Some
niche DSP might, but even then I doubt it. 32-bit integers are just do damn
useful; any CPU or microcontroller is likely going to have support for the
type. And if they do, the C language psABI is likely going to bind int to that
hardware type.
Moreover, I think Frederick is incorrectly reading the tea leaves here. The
move from 16- to 32- and thence to 64-bit wasn't driven by the need for larger
integers, but by the need for larger pointers. And we don't have a need for
larger pointers anywhere near the horizon. Nothing above 32 TB of RAM and 8
sockets of processors is commonplace. I know bigger machines exist, but there
must be at most tens of them in the world. That means around 128 TB (2^47
bytes) is the current maximum requirement, which is a full 3 orders of
magnitude away from the x86-64 theoretical limit for virtual address space.
In fact, the current trend is the other way around: break up the single, large
machine into many smaller ones that can work in a cluster. Further, because of
the memory requirements, we are seeing far more need for *smaller* data types,
not bigger. For example, I see a far greater need for instructions for 8-bit
multiplication with 16-bit accumulators than I see for 128-bit multiplication
with 256-bit results.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2025-03-31 04:25:32