ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá












     áòèé÷ :: Filmscanners
Filmscanners mailing list archive (filmscanners@halftone.co.uk)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[filmscanners] Re: Digital Darkroom Computer Builders?



Andras writes:

> Yes, but it's only Microsoft whose products
> I'm forced to use almost every day ...

You are actually required to use a lot of products with similar practices
every day, you just aren't aware of it.  Have you checked the margins on
Motorola and Intel microprocessors lately?  Do you think the telephone
company is charging for calls at cost?  _Everybody_ does this.

> Sure, but the jump from 32 to 64 bits address
> space gives us a hell lot more time than the
> jump from 16 to 32 or 8 to 16.

It doesn't matter; it will be used up just as quickly.

The mistake engineers make is in believing that address spaces will be
allocated sequentially starting with byte zero and ending with byte 2^N-1.
But that's not how it actually works.  Engineers tend to assume that a given
address space has "more space than anyone will ever need" and allocate the
space in extremely wasteful but easy-to-code ways that cause it to be
exhausted with alarming speed.

This is why the 32-bit IP address space is in such dire straits, even though
there are nowhere near 4 billion computers on the Net yet.  It is also why
IPv6 and IPv8 will suffer the same fate.  It is also why 32-bit computers
are reaching their limits even for mundane, everyday use.

Years ago I was already seeing systems exhaust 36-bit addressing spaces;
that's 64 billion bytes, easily a thousand times more than the physical
memory capacities available at the time.  Having 36 bits didn't do any good;
incompetent design and coding managed to exhaust address spaces of any size
in short order, no matter how large they were initially.

> Also, 64 bits take us to the physical limits
> of semiconductors ...

How?

> ... so you may be right that we will eventually
> need 128 bits, but that is a long long time
> away (decades, and many generations of computers).

Maybe, maybe not.  There are ways in which 64 bits could be exhausted in
just a few years.  I've seen things like that happen before.

> Sure, but this is merely a software question really.

Once the software is in place, it behaves like hardware.  Contrary to common
myth, even though software is not hardwired into a machine, it is
extraordinarily difficult to change, especially when loaded into hundreds of
millions of machines around the world.  If this were not the case, we would
have all moved to IPv6 overnight when IPv4 near exhaustion.

> Since modern operating systems have elaborate
> and flexible memory handling capabilities, and
> programs make no assumptions as to where in memory
> they are mapped, it's a matter of making modifications
> to the OS and BIOS to solve this problem.

Not really.  Individual applications must allocate virtual space in an
intelligent and economical way as well, and usually they do not.

> The fact that more expensive versions of
> Windows can address 3GB per process shows this.

Not relevant--these expensive versions of Windows still operate within the
32-bit restriction.  The fact that special versions were required even
before the 32-bit limit was reached, however, illustrates the magnitude of
the problem.

In the case of Windows NT and its successors, the problem is that the
original engineers very wastefully declared that 2 GB of the 32-bit address
space would be reserved for the OS, and 2 GB would be reserved for
applications.  Well, as time passed, the application space rapidly approache
exhaustion, while the OS space remained largely empty.  And so a lot of code
had to be rewritten to reduce the OS space and expand the application space.
If the original designers had demonstrated a bit more foresight, this would
never have been necessary.



----------------------------------------------------------------------------------------
Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe 
filmscanners'
or 'unsubscribe filmscanners_digest' (as appropriate) in the message title or 
body



 




Copyright © Lexa Software, 1996-2009.