Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
> In the light of this discussion, one has to wonder why would the average
> desktop user need a 64-bit system anyway. Are we going to eat up 4GB of
> RAM using word processors and browsing the web ? Talk about bloat :-)

  Remember the time when a 100MB hard disk was HUGE? Probably many thought
back then "why would the average user need such a huge hard disk?"
  This was probably the case with every major developement in computers.
And history shows us that even though we *now* can't think of anything
really necessary, there *will* be something. Resources create the needs.

-- 
                                                          - Warp

Post a reply to this message

Warp  wrote in message <44d09d1b@news.povray.org>:
>   I didn't understand this. What "such or such data structure" are you
> talking about, and what does virtual memory has to do with that?

Let us take a simple case: assume you have a simple but big list of big
objects. First, let us assume that all the objects fit in memory. Then, you
only have to use a big array of pointers to the objects, and everything is
said.

But if all the objects do not fit in memory, you will need to store some of
them on hard disk while you do not use them. For each object, either the
pointer is not null, and gives the address of the object, or it is null, and
the object is not present in memory, but saved in a file called
objXXXXXXXX.swap (where XXXXXXXX is the number of the object). Each time you
want to access an object, you have to check if the pointer is null; if it is
null, you have to pick another object and save it to disk to make room, and
load the object you want.

Saving and loading objects is a painful task. Checking for null pointers
everywhere makes your code more complex and slower. Furthermore, if your
data structure is more complex than an array of big objects, you have to
somehow store the status of each swappable part so it is always available,
which means using a pointer to pointer-or-null instead of a direct pointer.
Last of all, if your program is multithreaded, you have to lock even
read-only data structures to prevent it from being swapped out by another
thread. And you also need to make statistics usage of your object, to avoid
swapping out an object you will need a few milliseconds later.

Good news: all this is in fact built in the modern processors and operating
systems. For all memory references, processors are able to use the address
not as a direct reference to physical memory, but as a reference to a
translation table; they can suspend the course of the program and start a
specific processing if the translation table shows that the target is not
available; they can also maintain very basic statistics about access to
these references. Operating systems use these facilities, filling the
translation table and handling unavailable references, to provide to its
processes a virtual memory potentially much bigger than the physical memory
of the computer.

For example, on a host with 16 MB of memory and more than 2 GB of hard
drive, a process could run as if it had 2 GB of memory, the OS copying
chunks of memory to and from hard drive as needed. Depending on the pattern
of the memory accesses of the process, the result can be almost as fast as
if the computer actually had 2 GB of memory, or awfully slow.

In the cases where the result is bad, doing the swapping "by hand" as I
described earlier may give better results, because it is possible to use a
knowledge of the algorithm to better select parts of the data structure to
swap out or pre-fetch. But most of the time it will not do much good,
because some algorithms just can not be swapped. Thus, it is often better to
just let the OS do its work.

Anyway, such a mechanism is limited by the size of the input to the
translation mapping, compared to the size of the target objects. When it is
done explicitly, those can be chosen to match exactly the needs of the
program. On the other hand, when relying on the processor facilities,
everything is limited by the pointer size. So on a 32 bit processor, a
process can never see more than 4 GB of (virtual) memory at once. Everything
beyond must be done explicitly.

In a time when a computer with 32 GB of memory and 4 GB of hard drive was a
very powerful computer, that was quite ok. But in a time when any
supermarket computer has 1 GB of memory and 200 GB of hard drive, it is time
to step forward.

Post a reply to this message

Warp wrote:
>   I was just asking, out of curiosity, what is it that makes some people
> believe that a 64-bit system should/might be twice as fast (or just faster
> by some degrees) than an equivalent 32-bit system.

Analogies with other things that work that way, like a V-8 engine having 
twice the acceleration than a 4-banger.

>   It just feels that people never stop to think rationally about these
> things. "What does it actually mean that it's a 64-bit system?"

And some folks don't even know that much, before they ask. Some people 
learn this stuff from the top down, as it were. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     This octopus isn't tasty. Too many
     tentacles, not enough chops.

Post a reply to this message

Warp wrote:
> 
>   Most people are also probably too young to remember the shift from
> 16-bit systems to 32-bit systems in Intel-based computers and have never
> experienced first-hand the speed difference between a 16-bit binary
> compared to a 32-bit binary (if they do the same thing there's basically
> no speed difference except when big amounts of memory are needed or if
> 32-bit arithmetic is a very relevant part of the program's calculations).
> 
I even remember the shift from 8 to 16 bit systems.   :-)
I started with an Altair -- anybody remember them???
8080 processor running at 2Mhz.  It even started with a whopping 1K of 
memory!

      -=- Larry -=-

Post a reply to this message

"Ger" <No.### [at] ThankYou> schreef in bericht 
news:44d0700e@news.povray.org...
>
> On the other hand, did you stop to think that not everybody is familiar 
> with
> the inner workings of a computer? That there are actually very few people,
> compared to the numbers that use them, that are knowlegable about the 
> inner
> workings?
> Looking back I can see the validity in Stefan's reasoning.
> -- 

I totally agree!!!
Myself, I have not the slightest idea how that box to my left works. But as 
long as it does what I ask it to do, I am fine :-)
To tell the truth, beyond a basic knowledge, I don't want to know about the 
inner machinery.

Thomas

Post a reply to this message

Thomas de Groot <t.d### [at] internlnet> wrote:
> To tell the truth, beyond a basic knowledge, I don't want to know about the 
> inner machinery.

  You don't *want* to know? Why? Some weird principle?

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schreef in bericht 
news:44d30822@news.povray.org...
> Thomas de Groot <t.d### [at] internlnet> wrote:
>> To tell the truth, beyond a basic knowledge, I don't want to know about 
>> the
>> inner machinery.
>
>  You don't *want* to know? Why? Some weird principle?
>

Well, just because I feel it is a waste of time for me.

I have a PC for doing things I want it to do, I don't need nor want to know 
(most of the time) why or how it does it. I just don't have the basic 
knowledge and, frankly speaking, I have more interesting things to do.

This said however, I am always curious about what is said on the matter in 
the ng's by those who are more knowledgeable :-) just gleaning here and 
there a little bit of information that I may need some day.

I am fairly certain that there are a lot of people like me around here.

Thomas

Post a reply to this message

Thomas de Groot wrote:
> 
> Well, just because I feel it is a waste of time for me.
> 
> I have a PC for doing things I want it to do, I don't need nor want to
> know (most of the time) why or how it does it. I just don't have the basic
> knowledge and, frankly speaking, I have more interesting things to do.
> 
> This said however, I am always curious about what is said on the matter in
> the ng's by those who are more knowledgeable :-) just gleaning here and
> there a little bit of information that I may need some day.
> 
> I am fairly certain that there are a lot of people like me around here.
> 

Compare the number of people that know how a car functions to the number of
people driving a car. Same thing goes for computers. In the end they are
nothing but a tool to get something done.
-- 
Ger

Post a reply to this message

"Ger" <No.### [at] ThankYou> schreef in bericht 
news:44d34855@news.povray.org...
>
> Compare the number of people that know how a car functions to the number 
> of
> people driving a car. Same thing goes for computers. In the end they are
> nothing but a tool to get something done.
> -- 

Exactly my point.

Thomas

Post a reply to this message

Larry Hudson <org### [at] yahoocom> wrote:
> Warp wrote:
> >
> >   Most people are also probably too young to remember the shift from
> > 16-bit systems to 32-bit systems in Intel-based computers and have never
> > experienced first-hand the speed difference between a 16-bit binary
> > compared to a 32-bit binary (if they do the same thing there's basically
> > no speed difference except when big amounts of memory are needed or if
> > 32-bit arithmetic is a very relevant part of the program's calculations).
> >
> I even remember the shift from 8 to 16 bit systems.   :-)
> I started with an Altair -- anybody remember them???
> 8080 processor running at 2Mhz.  It even started with a whopping 1K of
> memory!
>
>       -=- Larry -=-


calculator hiding some where. Now that my job does not depend on it like

goes fast enough.

Stephen

Post a reply to this message