Jump to content

Can you create more memory from memory


fredreload

Recommended Posts

Quote

Can you create more memory from memory?

 

You can compress data to store the same amount of data but in smaller buffer.

Compression can be lossless or lossy compression

https://en.wikipedia.org/wiki/Lossless_compression

https://en.wikipedia.org/wiki/Lossy_compression

 

In some cases like 3D graphics you can store information how to recreate 3D object with very high precision from scratch, instead of storing the all vertexes and polygons in raw format.

e.g. instead of storing the all characters of every word of every page of text document, you can just store information about index of word (or entire sentence, often repeated) instead. And make dictionary with words. One common dictionary of words for couple books (entire library?) would allow even higher compression rate.

 

 

 

Edited by Sensei
Link to comment
Share on other sites

Right but with each increasing bit you can store a considerable amount more memory. For instance we use a 32 bit integer, why not 64 bit, 128 bits.

5 minutes ago, DrP said:

125 bytes?

Yes every 8 bits is 1 byte, but every 9 bits is 2 bytes, and every 10 bits is 4 bytes, 1000 bits = 2^992 bytes

Edited by fredreload
Link to comment
Share on other sites

3 minutes ago, fredreload said:

Right but with each increasing bit you can store a considerable amount more memory. For instance we use a 32 bit integer, why not 64 bit, 128 bits.

No, no "more memory"... more data... higher resolution, higher precision integers, higher precision floating point numbers.

 

64 bit applications have 64 bit integers and 64 bit address pointers. So they use MORE MEMORY for the same. And they work slower than 32 bit equivalent application.

But in some cases, when application is using more than 4 GB of data, it's necessary.

 

Edited by Sensei
Link to comment
Share on other sites

Quote

For instance we use a 32 bit integer, why not 64 bit, 128 bits.

That refers the wires that run into the computer processor or ALU. Space is a consideration there was a time when a 64-bit computer would be very heavy and therefore no good for laptops etc.

 

Link to comment
Share on other sites

21 minutes ago, fiveworlds said:

That refers the wires that run into the computer processor or ALU. Space is a consideration there was a time when a 64-bit computer would be very heavy and therefore no good for laptops etc.

 

Ya, but does that also apply for data transfer like the internet?

24 minutes ago, Sensei said:

No, no "more memory"... more data... higher resolution, higher precision integers, higher precision floating point numbers.

 

64 bit applications have 64 bit integers and 64 bit address pointers. So they use MORE MEMORY for the same. And they work slower than 32 bit equivalent application.

But in some cases, when application is using more than 4 GB of data, it's necessary.

 


I was thinking of building a storage device in graphics space and placing a computer inside a computer and run genetic algorithm on it.

Edited by fredreload
Link to comment
Share on other sites

4 minutes ago, fredreload said:

Ya, but does that also apply for data transfer like the internet?

No, pointers to memory are not transferred through Internet. They are local to CPU.

Files are the same whether you compress them on 32 bit or 64 bit machines.

If file uses 64 bit integers, 32 bit machine can read such file without problem.

Link to comment
Share on other sites

5 minutes ago, Sensei said:

No, pointers to memory are not transferred through Internet. They are local to CPU.

Files are the same whether you compress them on 32 bit or 64 bit machines.

If file uses 64 bit integers, 32 bit machine can read such file without problem.

Precisely why they should make a 128 bit internet, I guess that depends on the package size, but you get the point. Like if I am transferring 1MB of 8 bit data vs transferring 1MB of 16 bit data really does make a differencec

Edited by fredreload
Link to comment
Share on other sites

7 minutes ago, fredreload said:

I was thinking of building a storage device in graphics space and placing a computer inside a computer and run genetic algorithm on it.

"graphics space"? Do you mean gfx card memory? They have much smaller capacity than typical physical memory available to CPU..

1 GB, 2 GB.. while e.g. DIMM/DDR (on mb) have now 8,16,32 GB per single module.

Link to comment
Share on other sites

7 minutes ago, Sensei said:

"graphics space"? Do you mean gfx card memory? They have much smaller capacity than typical physical memory available to CPU..

1 GB, 2 GB.. while e.g. DIMM/DDR (on mb) have now 8,16,32 GB per single module.

Graphics space as of gaming space 3D world like minecraft. Then I create a computer in the minecraft 3D game capable of hosting an even bigger minecraft 3D world. But as fivespace mentioned, it really depends on the computer and the buses

Link to comment
Share on other sites

16 minutes ago, fredreload said:

Precisely why they should make a 128 bit internet,

Nonsense..

You have IP v4 with just 4 bytes (4x 8 bits) per address = 32 bits IP address.

but there is also newer IP v6 with much higher resolution. 8x 16 bit shorts = 128 bits IP v6 address.

https://en.wikipedia.org/wiki/IPv6

16 minutes ago, fredreload said:

I guess that depends on the package size,

You don't want to have too large chunks.. Even 1 KB can be too big (especially for 3D real-time games!)..

Here you have f.e. discussion about packet sizes:

https://stackoverflow.com/questions/2613734/maximum-packet-size-for-a-tcp-connection

Quote

but you get the point

No, I did not..

 

Edited by Sensei
Link to comment
Share on other sites

1 minute ago, Sensei said:

Nonsense..

You have IP v4 with just 4 bytes (4x 8 bits) per address = 32 bits IP address.

but there is also newer IP v6 with much higher resolution. 8x 16 bit shorts = 128 bits IP v6 address.

https://en.wikipedia.org/wiki/IPv6

You don't want to have too large chunks.. Even 1 KB is way too big..

Here you have f.e. discussion about packet sizes:

https://stackoverflow.com/questions/2613734/maximum-packet-size-for-a-tcp-connection

No, I did not..

 

Well the packet is probably built out of 32 bit not 64 bits.

Link to comment
Share on other sites

9 minutes ago, fredreload said:

Well the packet is probably built out of 32 bit not 64 bits.

Do you even realize that single couple hundred KB file (not to mention MB, or GB) has to be split to hundred little chunks... ?

If transmission of single chunk e.g. 1 KB is corrupted, just resending single chunk 1 KB chunk is needed, instead of restarting entire transmission from scratch..

Nobody needs/wants 64 bits+ chunks.

 

 

Edited by Sensei
Link to comment
Share on other sites

 

2 hours ago, fredreload said:

Like if I am transferring 1MB of 8 bit data vs transferring 1MB of 16 bit data really does make a differencec

1MB is 1MB whether you think of it as bytes (8 bits) or words of 16, 32 or 64 bits. So it makes no difference. 

2 hours ago, fredreload said:

Well the packet is probably built out of 32 bit not 64 bits.

Pretty much all networks are bit-serial so whatever size your data is, it will be sent one bit at a time. But that bit stream is split into packets of about 1500 bits. 

3 hours ago, fredreload said:

Yes every 8 bits is 1 byte, but every 9 bits is 2 bytes, and every 10 bits is 4 bytes, 1000 bits = 2^992 bytes

Huh?

1 byte is 8 bits. 2 bytes is 16 bits, not 9. 

But if you are talking about addresses not data then 8 bits can address 256 bytes. 9 bit can address 512 bytes and so on. 

2^992 bytes is billions of times more storage than exists in the entire world. 

Edited by Strange
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.