Sammy, I am beginning to come around to your way of thinking

Sammy writes:

> You can subdivide the address space but doing so doesn't make it
> suddenly get used up exponentially.

Subdividing the address field will.

> I don't know what sort of software you work on, but if it's
> transaction processing or you have lots of concurrent users you give
> each session a whole address space to play with instead of swapping
> them in and out.

Transaction processing can be done with very small amounts of memory per user.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Sammy writes:

> You're using vague terms which confuse how an address space is divided
> into subspaces with how it is allocated for each object.

No, I'm not.

> IPv4 addressing is not the same as x86 memory architecture.

The concept is the same.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Oi, leave my thread alone you hijackers!

"Sammy" <syousef.DeleteThis@bigpond.net.au> wrote in message
news:1180846709.907716.288800@r19g2000prf.googlegroups.com...
> On Jun 3, 10:33 am, "Mike Young" <boat042-s....DeleteThis@yahoo.com> wrote:
>> The question isn't how the programmer will use it, linearly or
>> exponentially. I don't even know where to begin thinking in those terms.
>> That's probably where you're drifting, also. Bear with me for a moment
>> for
>> the relevance to IP address classes.
>
> Linear and exponential have a very well defined meaning and are being
> thrown about without any context here. What do you mean by "use it,
> linearly or exponentially"? How does one use memory "exponentially".
> You can subdivide the address space but doing so doesn't make it
> suddenly get used up exponentially.
>
>> The 64-bit address space is *huge*. What will you do with it? What will
>> an
>> application do with it?
>
> Well for starters you might have HUGE data. An uncompressed video file
> comes to mind.
>
>> What application programmer can even begin to
>> conceive of using even a measurable fraction of it?
>
> I've not regularly had to manipulate large data sets but its not
> uncommon for scientific work. For the home user imagine not having to
> swap pieces of your 100Mb tiff in and out so you can handle multiple
> images simultaneously, or retaining a large undo buffer in graphics
> editing software. I already mentioned video. A terrabyte really isn't
> as big as people seem to think it is. I have well over a TB on my
> computers here at home.
>
>> I work with systems that
>> are routinely in danger of exceeding their 2 GB process user virtual
>> space.
>> I can make good use of just a bit more headroom. Pun intended. Just one
>> more
>> bit doubles my virtual space. What will I do with the other 31 new bits?
>
> I don't know what sort of software you work on, but if it's
> transaction processing or you have lots of concurrent users you give
> each session a whole address space to play with instead of swapping
> them in and out. There's a lot of very memory hungry software out
> there. I work with J2EE environments and one limitation you encounter
> is a slowdown due to swapping sessions in and out of memory.
>
>> Here's where it would benefit me. At the application level, I don't
>> particularly know or care whether an address range is in RAM or paged to
>> disk. I care, but the OS will do what it's gonna do regardless. If we
>> extend
>> that thought just a little, I really don't particularly *like*
>> manipulating
>> files on disk. Wouldn't it be just wonderful if some directory service
>> would
>> map what I now think of as "g:\games\fsx\fsx.exe" into my huge, flat
>> address
>> space?
>
> What you're describing is a RAM disk and has been around for a very
> long time. (You use to use them explicitly in the DOS and win 3.11
> days) The trouble at the moment is that RAM is much more expensive
> than disk so you have to have a pretty good reason to do this.
>
>> Once you start down this path, there's no end to the familiar
>> abstractions
>> that can be made to go away. Applications don't care or really want to
>> know
>> about IP addresses and TCP ports. They just want to poke some data to
>> that
>> service there, wherever 'there' might be. So these aren't really
>> abstractions after all; IP addresses and filenames are implementation
>> artifacts.
>
> Again there are differences between local memory to which you can
> access very quickly indeed and applications that have to fetch data
> across the network. You deal with the situation you're describing
> easily enough by abstracting the comms layer of your software so the
> application doesn't need to know about it. However the developer still
> must be aware of the difference or you end up with horrendously slow
> applications fetching across the network.
>
>> A 64-bit address space is usefully large enough that I can begin to think
>> about making those artifacts go away. I can begin to abstract them into
>> the
>> more familiar and comfortable flat memory space.
>
> ...but the architecture allows you to deal with it as flat.
>
>> The question then becomes how will I carve it up?
>
> Unless you're using a low level language you don't worry about this.
> You simply allocate and deallocate from a common heap. With most
> modern languages you don't manually manage memory because that is very
> error prone indeed. C and C++ are still common for games programming
> though and there you do have to manual memory management (and hence
> you can get memory leaks). Languages like Java try to ellminate this.
>
>> Does it make sense to carve it up? Should we
>> allocate some of it to represent local disk storage? How much? What if,
>> instead of poking data to a service, I just write it to an address space
>> we
>> both share? Even the concept of poking data to a service becomes an
>> artifact.
>
> How is this a linear vs exponential problem?
>
>> I'm making it up as I go. How does it sound so far?
>
> See above.
>
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

"Sammy" <syousef.TakeThisOut@bigpond.net.au> wrote in message
news:1180846709.907716.288800@r19g2000prf.googlegroups.com...
>> Does it make sense to carve it up? Should we
>> allocate some of it to represent local disk storage? How much? What if,
>> instead of poking data to a service, I just write it to an address space
>> we
>> both share? Even the concept of poking data to a service becomes an
>> artifact.
>
> How is this a linear vs exponential problem?

Same example I gave before. Some dummy carved out a whole Class A and
assigned it to loopback. Is that linear? Stretch a little; you can get
there.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

On Jun 3, 5:16 pm, "Mike Young" <boat042-s... RemoveThis @yahoo.com> wrote:
> The progression in class sizes is exponential. Stretch a little, Sammy. The
> last thing I wanted to do was agree with MX.

Yeah right. Gimme a break.

You're right about one thing. It is a stretch. Take a look at the
message dated May 30, 4:36 pm - 13th in my threaded view on Google
groups. I don't need a lecture on how the address space is dependent
in an exponential way on the number of bits used to hold the address.

We disagreed when Mx said:
"Addressing issues are the most consistent area of mistakes made by IT
engineers for as long as IT has existed. As a result, the amount of
time
required to exhaust an address space varies almost linearly with the
length of that address space in bits."

If this were true, we would have very little memory addressable in a
modern computer. I remember having a computer in 1980 that had a 64kb
memory. A year or 2 later Commodore 128 was the bees knees. If this
trend had continued. I think we'd be up to 2Mb by now instead of 2Gb..

Apparently he's now talking about the way an address space is carved
up. Yes historically address spaces were cut up that way because it's
quicker to use XORs, SHIFTs and other bitwise operations to split up
an address, and for that you do need to make addressing work on a bit
boundary, so yes some address spaces were split up at exponent
boundaries. (Not always. Not since we had to worry about real and
protected memory in the bad old DOS days have high level processes had
to worry about this kind of thing. Remember DOS4GW for gaming?)
However to suggest that this means that the address apace grows in a
linear fashion is just plain wrong. No stretch, no difference in point
of view will change that.

Mx continually shifts the goal posts when he argues, and in
acknowledging that and asking me to "stretch" you're doing no more
than feeding a troll. I'm not sure if you're doing it on purpose or
not and frankly I just don't care.

I have more important things to do with my life than continue this
absurd conversation. I will not be reading this thread again.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

"Sammy" <syousef.TakeThisOut@bigpond.net.au> wrote in message
news:1180846709.907716.288800@r19g2000prf.googlegroups.com...
> On Jun 3, 10:33 am, "Mike Young" <boat042-s....TakeThisOut@yahoo.com> wrote:
>> The question isn't how the programmer will use it, linearly or
>> exponentially. I don't even know where to begin thinking in those terms.
>> That's probably where you're drifting, also. Bear with me for a moment
>> for
>> the relevance to IP address classes.
>
> Linear and exponential have a very well defined meaning and are being
> thrown about without any context here. What do you mean by "use it,
> linearly or exponentially"? How does one use memory "exponentially".
> You can subdivide the address space but doing so doesn't make it
> suddenly get used up exponentially.

The progression in class sizes is exponential. Stretch a little, Sammy. The
last thing I wanted to do was agree with MX.

A few question for ya, and this is my last try. I'm not as much interested
in your answers as I am in leading your thoughts in a certain direction.

32-bit Windows applications have a 2 GB virtual space. What happened to the
other 2 GB of the 4 GB directly addressable with 32-bits? (Is halving a
space not exponential?)

A memory address, more specifically the value in an application's pointer,
is valid only within that process. You can't pass it meaningfully to another
process. Agreed? There are times when it would be useful to look inside
another application's memory space directly and make sense of it. Sharing a
coherent view of the memory space is already readily possible. The trouble
is, say the data structures are non-trivial, and contain pointers. Given
carte blanche, how would you allow the second process to make direct use of
the data, pointers and all? Is there any solution you can think of that
doesn't require setting aside a pre-agreed range of addresses for that use?

Assuming you arrived at the conclusion that you do indeed carve out and
pre-allocate ranges in the address space for particular use, is there any
scheme that would work in binary, von Neumann architectures that are not on
power-of-2 size boundaries? If they need not all be the same size, but only
need to be power-of-2 in size, is not the relationship then exponential
rather than linear?

So what's the relevance to me, whether it's exponential or linear? None,
nothing, nada, zero, zilch, zip. I'm not on a standards committee, and I'll
be long since retired before some yahoo finds a way to bloat TIF's and
uncompressed video to fill my 64-bit address space.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Mike Young writes:

> Same example I gave before. Some dummy carved out a whole Class A and
> assigned it to loopback. Is that linear?

Yes. It's a linear allocation of the address field, and an exponential
sacrifice of the address space.

> Stretch a little; you can get there.

Some can, some can't. Even on the IETF some people don't understand the
problem. That's why the same mistakes are being made with IPv6.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Mike Young writes:

> I'm not on a standards committee, and I'll
> be long since retired before some yahoo finds a way to bloat TIF's and
> uncompressed video to fill my 64-bit address space.

Unless you're retiring in the next few years, you'll probably still be in
business when it happens.

Engineers make several key mistakes, again and again: (1) they don't realize
that encoding information in the address field produces a linear reduction in
the size of the field but an exponential reduction in the address space; and
(2) they think they can foresee all future requirements in advance, and so
they want to allocate everything up front rather than leave space undefined or
unallocated for future use. The combination of these exhausts address spaces
with astonishing speed, and it's linear, so going from 64 to 128 bits only
roughly doubles the longevity of an addressing scheme, contrary to what one
might think from looking at the theoretical size of the address spaces.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Sammy writes:

> If this were true, we would have very little memory addressable in a
> modern computer.

We have about the same as we did when PCs were invented. Every increase has
been immediately soaked up by software bloat and poor design. A 32-bit
address space has 16 million times the size of a 16-bit address space, but we
aren't getting 16 million times the productivity. In fact, productivity seems
to vary more in linear fashion with the address-field length than in
exponential fashion with the address-space size.

> Apparently he's now talking about the way an address space is carved
> up. Yes historically address spaces were cut up that way because it's
> quicker to use XORs, SHIFTs and other bitwise operations to split up
> an address, and for that you do need to make addressing work on a bit
> boundary, so yes some address spaces were split up at exponent
> boundaries.

It is STILL done that way. Nothing has changed, and that's the problem.

> Mx continually shifts the goal posts when he argues, and in
> acknowledging that and asking me to "stretch" you're doing no more
> than feeding a troll. I'm not sure if you're doing it on purpose or
> not and frankly I just don't care.

You keep saying you don't care, but you keep arguing.

> I have more important things to do with my life than continue this
> absurd conversation.

And yet here you are.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

On Jun 3, 11:55 pm, Mxsmanic <mxsma....DeleteThis@gmail.com> wrote:
> We have about the same as we did when PCs were invented. Every increase has
> been immediately soaked up by software bloat and poor design.

What a complete and utter load of bullshit. Your grandiose posturing
just pisses me off.

When the PC was invented the idea of it being used to decode a
compressed video stream in real time was preposterous. We dealt with
tiny files and even decoding a small zip file would take a long time.
Transferring files a few megabytes in size took forever on a modem.
The first flight simulators were little more than stick figure
representations because loading a single texture in one of today's
simulators would have taken seconds instead of milliseconds, and the
hardware didn't exist that was fast enough to render it.

Yet you think you're so intelligent that you dismiss all of this and
suggest that our increases have been "linear". It's true that there
have been tradeoffs and that some software is bloated and/or badly
designed, but you could certainly do no better. There has also been
some fantastic design and some incredible leaps forward.

> A 32-bit
> address space has 16 million times the size of a 16-bit address space, but we
> aren't getting 16 million times the productivity.

Ah shifting the goal posts again. Typical of your inane style of
arguing. Now we're not talking about allocation, or address space
division, but productivity.

> In fact, productivity seems
> to vary more in linear fashion with the address-field length than in
> exponential fashion with the address-space size.

Productivity as measured by what exactly? Your subjective nonsense?

Ever heard of Moore's law? (Law being a misnomer, it should be Moore's
observation) Every time you decompress a large file. Every time you
watch a video stream. That's only possible because people have
dedicated their lives to developing algorithms that allow these things
and that make use of the PC non-linear growth in computing power
efficiently.

> It is STILL done that way. Nothing has changed, and that's the problem.

It's still done that way for architectures developed in the 60s yes.
These architectures complete with their inefficiencies are the stable
base without which the Internet could never have taken shape. Not
every address space has been subdivided in the way you're discussing.

> You keep saying you don't care, but you keep arguing.

Yes because you keep saying things in an attempt to sound smart that
get more and more preposterous. Again typical of you, if I don't argue
your BS stands, and if I do argue you attack me for that. In other
words you're trying to create a situation where I feel I have to
respond despite not wanting to waste the time so that you can attack
that.

> > I have more important things to do with my life than continue this
> > absurd conversation.
>
> And yet here you are.

Yes, because the nonsense a troll spouts is dangerous.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Mxsmanic wrote:

> IPv4 is in danger not because there are literally 4+ billion computers
> connected to the Net, but because the address space has been exponentially
> eroded by linear allocation of the address field bits. Exactly the same thing
> will happen with IPv6 (it is _already_ happening), meaning that IPv6 will
> perhaps last four times as long as IPv4, instead of 2^96 times as long.

Think this is where we have been at cross-purposes

In terms of IPv6, this is 128bit, and should be enough. However, as we
saw with IPv4 when some firms were given 16million reserved addresses
and only used a fraction of them; a similar issue could occur with IPv6.

However, the jump from a 32bit scheme to a 128bit scheme is huge; we
would never run out of usable space, just much of it would be reserved
and thus unused.

Can't see there being a problem in my lifetime

Mind you, the big problem comes when we have to move to IPv6 - March
2010 I believe is the date set for when IPv4 runs out.
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

C6 wrote:
> Tilly, I finally settled on XANA-News. It's free and after some trial
> and error I have it configured just right for me. You can make it look
> different until you have it right for you. I've got it threading now
> just fine.

Going to D/L and give it a go now. I used to have AMEOL years ago, and
Virtual Access but ended up losing the floppy disks! Yep, them were the
days
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking 

Sammy wrote:

> Another common misconception. You can be just as lazy with a non-RAD
> environment, it's just that it's a lot harder to get anything done so
> if a programmer is successful at building software using the more
> complex non-RAD environment, they're also more likely to know how to
> trap an error and be disciplined about it. Unfortunately the current

Agree, you can be a lazy programmer full stop whatever tool you use

This is not to belittle the efforts of the programmer, after all we have
moved on quite a way from the days of Assembler.

The move towards a web app will also change the model of software
licencing as we know it. The future will be pay-as-you-go

Wonder how they are going to fit all that flight-sim stuff into a
web-app. I am sure it will be done eventually, and real-time linkups
will add to the "experience" but we sure as hell are going to need more
bandwidth

Bandwidth will determine whether the pay-as-you-go model really takes
off. Here in the UK, as usual, miles behind the rest of the world as BT
takes it time to deliver the bandwidth needed for the next decade
 >> Stay informed about: Sammy, I am beginning to come around to your way of thinking