So we had 32bit, how it performed in processing everything from

Kek
He's not even baiting, he's this retarded

It won't happen any soon because 64 bits allow to use like ~2TB of RAM.

>>57042863
>implying we will reach 18446744 TB of RAM within the next 50 years

>>57042892
> implying we will reach 2000000000B of within the next 50 years
> nobody needs more than 512 B

File: spoopy aliasing.gif (793KB, 400x400px) Image search: [Google]

793KB, 400x400px

>>57042882

It's a valid question.

>>57042887

Think about how much 2GB was a generation ago.

Could potentially be burning through a petabyte in another decade.

File: when you drop something under the bed.jpg (320KB, 1280x1024px) Image search: [Google]

320KB, 1280x1024px

>>57042863
Doesn't work like that.

>>57042947
It's not you retard. We won't need that much memory in our lifetimes. Not even the next two or three generations will.

>>57043047

So where does the current bottleneck of performance stand now?

>>57043020

How does it work?

>>57042977
Really? Because a computer I bought 5 years ago had 8 GB of RAM. If I were to buy a new one at the moment, I would get 16GB at most. So if we're looking at recent trends here, the RAM use really isn't increasing very quickly compared to what it did in the past.

>>57043112
I remember when Doom 3 came out and it needed a staggering 1 GB of RAM. My first WinXP installation was on a K6-2 with 64 MB of RAM, and it ran Sims 1 like a dream.
(The loading time was 5 minutes, though)

>>57043112

There was a man named Moore, he had a very interesting observation.

>>57043147
Moore's law seems to be breaking down elsewhere as well. Even Intel has admitted that 10nm and 7nm processes will take a longer time to bring to the market, and even then the current "14nm" processes are 14nm in name only.

>>57042863
We have 128/256/512 bit CPU extensions like AVX

>>57043020
Then who was carpet?

OP, computers are not like videogames. 16/32/64 bits are addressing modes. They don't actually indicate the "power" of the processors. It just means the processor can access memory units that are that 16/32/64 bits "wide". Making a "128-bit" processor wouldn't make a processor more powerful.

Actually, the "bit war" was just a marketing gimmick from those bygone eras. Bits aren't "power", but "memory".

There are 128, 256 and 512-bit processors, but they aren't used on consumer computers.

>>57042882
>"So where does the current bottleneck of performance stand now?"
>>57043098

yea, you were right, he is retarded

>>57043201
it's not just addressing; numbers requiring >32 bits would otherwise need routines to be operated on as opposed to natively

if you want to talk about addressing; most 64bit CPUs only actually use 48 bit addresses

>>57043237
I heard this once in a class, but I forgot to ask for clarification. By "natively", do you mean the operation is done completely by hardware and logic, instead of virtual addressing?

>>57043270
what I mean is that you have 64 bit registers, and when the "add" instruction is used, two 64 bit numbers are added by the hardware.
if I had 32bit registers and I wanted to add a pair of 64 bit numbers, I'd need to sum the rear end, check for overflow, adding 1 to the front 32 bits of one of the numbers, then sum the front 32 bits.

>>57042887
Its way higher than that.

Theorically, 64 bit allows 16EiB of ram. In practice, amd64 allows only 4PiB of physical memory and 256TiB of virtual memory.

>>57043020
That's what you get for skimping on the PSU.

>>57043205
Fpbp 2bfh

>>57042863
The only thing 64 bit is faster at, is dealing with numbers greater than 32 bit. 32 bit systems use two fetches, two puts, etc. The vast majority of the data a processor handles is 32 bit or less.

The performance increase you're attributing to moar bits, was actually due to better processor design, shrinking manufacturing processes, higher speed memory, and better compiler designs.

>>57042887
It's not just about RAM and you can always do PAE.

But probably won't see 128bit or even much past 64bit for a long time, if ever. We've come up with some decent schemes for handling very large numbers, from what I've read.

>>57043020
Are those bugs?

it's actually just a bunch of architectural improvements like OoO claimed to be brought by 64 bit, thats about it, and moar registers

>>57043415
just features

>>57042863
128bit will never happen

>>57043448
kek

>>57043020
did he died?

>>57043319
>what are CPU extensions

AVX2 can operate natively on 512 bits, recent CPUs support operations natively on 128bits integers.

Doesn't make them 128bit CPUs.

>>57042863
128 bit cpus already exist, as do 256 bit cpus. You won't be seeing them on desktops for decades, if ever however. There's no point. 64 bit cpus are more than sufficient for anything outside of the super computer market. Hell, it's only been in the last few years that software developers have begun to really take advantage of 64 bit cpus, and they've really only scratched the surface of what they are capable of.

Not gonna be seeing this in consumer hardware for a while, because 64-bit's main purpose isn't to handle 64-bit integers, but to address more RAM.
64-bit provides more RAM addressing than we'll need for some time.

>>57043399
PAE doesn't allow you to use more RAM per process though. Just allows the machine to have more RAM. So, for instance, you could run two separate database processes with 4GB each, but not one database processes with >4GB.

Also, you have a constant performance hit with PAE enabled. Whether it's using it or not.

>>57043451
Has happened. Never makes it out of the lab. Just not currently useful for general purpose machines.

>>57042892
>what are 3D videos

>>57046259
To be fair, we still won't need THAT much.

>>57046207
>PAE doesn't allow you to use more RAM per process though.
Yea, but even back in the 32 bit days you didn't really run into that issue.
>Also, you have a constant performance hit with PAE enabled. Whether it's using it or not.
We are talking about personal computers, not workstations or servers, right?

>>57046464
Yeah. But whether it's a workstation or server enabling PAE had a consistent hit. Just not worth it usually.

>>57043147
The topic is RAM.
You bring in Moore.

Are you serious??

>>57047378
For consumers it wasn't really noticeable. For servers and workstations, sure, but they already have solutions.

File: AHHHHHHHHHH.png (293KB, 633x758px) Image search: [Google]

293KB, 633x758px

>tfw fell for the 16PiB meme

>>57043112
>RAM didn't get faster

kek urself

>>57048664
Kinda didn't.

>>57043169
> Even Intel has admitted that 10nm and 7nm processes will take a longer time to bring to the market, and even then the current "14nm" processes are 14nm in name only.

And Intel are fucking jews who take their sweet time because AMD sucks so much.

Things would be different if they had an actual competitor.

>>57042863
64 Bit is enough for addressing RAM, so all operations which do stuff with memory addresses don't need more than 64 Bit. For everything else there is AVX(2). So if you have a CPU which is not more than about 5 years old you probably already have a processor which is able to compute with 256 Bit numbers in hardware without the need for subroutines.

>>57050653
Intel's already stated their business model is shifting to embedded / phone, so they have a vested interest in getting to lower nm because of reduced power consumption. But at that small of a size you're dealing with significant subatomic phenomena like quantum tunneling, which is why it's so slow

But I'm sure you knew that and you're not a complete dumbass :^)

>>57043047
Oddly Bill Gates stated in the 90s
>>I laid out memory so the bottom 640 K was general purpose RAM and the upper 384 I reserved for video and ROM, and things like that. That is why they talk about the 640 K limit. It is actually a limit, not of the software, in any way, shape, or form, it is the limit of the microprocessor. That thing generates addresses, 20-bits addresses, that only can address a megabyte of memory. And, therefore, all the applications are tied to that limit. It was ten times what we had before. But to my surprise, we ran out of that address base for applications within—oh five or six years people were complaining.

So maybe it's not so stupid.... maybe some breakthrough will make that much memory available suddenly.

Maybe WE will be surprised

>>57042863
Ibm already holds 128 bit patents. Theres no use for it yet

>>57042863
The only significant improvement that accomplishes is more addressable memory, the register sizes themselves don't really affect performance since you can easily get around it with efficient software. Performance improvements will come from increasing register amount/density and improving the optimization at both the HW and SW levels.

That being said 128 bits will probably become standard eventually, I give it at least 3 more decades

>>57046305
>Not 2x 2d arrays of 24 bit pixels
>A single 3d array of pixels, each pixel with rgba data
>Entire scenes in memory as a single frame

>>57048664
What the fug am I reading

>>57048664
Ram didn't get faster retard. Ram is literally the bottleneck for computation right now. DDR4 isn't even better than DDR3 because latency.

>>57051638
I don't think I've ever heard of a vector unit not being 128-bit or greater.