By: anon (anon.delete@this.anon.com), August 21, 2013 5:40 am
Room: Moderated Discussions
⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on August 21, 2013 4:12 am wrote:
> anon (anon.delete@this.anon.com) on August 21, 2013 2:09 am wrote:
> > ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on August 20, 2013 11:29 pm wrote:
> > > 64-bit address space isn't a necessity.
> >
> > Yes it is, for the kernel, and for quite a few large applications,
> > ranging from databases, to hpc, to cad and media editing.
>
> You did not carefully read my post. The model I described does work if the computer has for example
> 32 GiB physical memory (which is 8x more than the 32-bit address space).
Wrong. You did not read my reply. I did not say your stupid model of splitting up apps and over complicating them due to lack of address space would not work. I said that the required kernel facilities that do not exist in your fantasy world, but have existed for decades in the real one, are not inhibiting this model from being implemented.
The fact is that the necessity does not come about because the kernel limits inter process communication and sharing. It is because it is not practical or economical to redesign hugely complex programs into a suboptimal form in order to accommodate for limited hardware.
The correct approach is to use the correct hardware design for the job.
> The applications you
> mentioned can be split into multiple 32-bit processes: Media editing can be very easily split
> into multiple 32-bit processes. If you put a two-stage application-level "page table" into a database
> application, you can easily divide it into multiple 32-bit processes/threads. Etc.
The applications I mentioned don't even need to be split. They can window into physical memory if needs be (this is what Oracle did).
I did never imply that was impossible, when I said 64-bit was a necessity (which it is).
>
> In other words: You are very impatient. Not because you are inherently stupid, but because you didn't
> want to spent the time needed to find the rationale behind my arguments. The several minutes you spent
> responding to my post clearly aren't enough for you to understand what I described in my post.
You should take your own advice, but in your case, you are inherently stupid.
>
> > Real users were hitting 32-bit x86 limits 10 years ago. Probably more.
>
> Yes. That is what I wrote. We were hitting the limits of the 32-bit address space.
Yep. Sucks for your argument, doesn't it?
>
> > > 32-bit address space is big enough for 99.9% of programs.
> >
> > "Most do not require it, therefore nobody requires it."
> >
> > See the logical fallacy?
>
> Yes. I saw it clearly while I was writing my post. It is curious
> that you considered worth your time to react to such a fallacy.
Of course you don't care for logic.
>
> > > In 99.9% programs, 64-bit address space has no performance advantage over a 32-bit address space.
> > >
> > > The non-existent things that AMD actually did exploit were:
> > >
> > > (1) The absence of an easy and safe way to do inter-process page mapping.
> >
> > Wrong. This exists in Linux and POSIX for ever.
>
> It only means that I do not agree with some parts of the POSIX model.
Which you fail to specify, of course.
>
> > > In particular it is the absence of
> > > the following programming pattern: 32-bit process X selects a page P from its address space and directly or
> > > indirectly tells the OS kernel to map the page P into the address space of the 32-bit process Y. The page P
> > > has the same 64-bit physical memory address, but its 32-bit virtual addresses in X and Y are different.
> >
> > You either fail to describe your programming pattern properly,
>
> I think it isn't necessary to describe it in greater length, due to multiple reasons.
I think that there is only one reason, and that is that you are a spectacular nincompoop.
>
> > or do not understand the concept
> > of a unix process. Because either 1) this is already trivially possible, or 2) it is idiotic.
> >
> > One process does not change the structure of another process address space.
> > This is simply not done, for good reason. Threads exist for this reason.
>
> The distinction between a Linux process and thread wasn't important enough for me to mention it in my post.
Your idiotic example is describing *the fundamental* difference between processes and threads. That is: threads of execution will either modify the address space of one another, or they will not.
>
> > On the other hand, you can trivially set up a communication mechanism between two processes and make them
> > do whatever you like. Process X can trivially tell process Y to perform some address space operation.
>
> If it is trivial, why aren't common Linux applications doing it?
Because your idea to split things into multiple processes in order to address more ram is stupid.
>
> > >
> > > (2) Complete lack of data serialization functions that
> > > would be built into mainstream programming languages.
> > > That is, the programming language needs to have a couple
> > > of builtin functions for transforming graphs of objects
> > > or structs into binary representation and for restoring
> > > such graphs from binary data. All that is needed are
> > > these two functions: bytes=save(x), y=load(bytes). I have
> > > implemented such functions in a programming language
> > > of my own, and the presence of such functions in the programming
> > > language makes a big difference in terms of
> > > communication between parts of a single program and in terms of communication between different programs.
> >
> > That's idiotic. There is no fundamental reason to put a data serialization protocol into a programming
> > language, and nothing preventing serialization functions from being used. Which they are. Widely.
>
> A fundamental reason preventing serialization functions from being used is:
> distance to the functions (ease of use from any point in a program).
What kind of nonsense is this?
>
> > >
> > > Case (1) obviously covers binary data only. For example, it can be used
> > > to send pixels to the X server. Secondly, it can be used by case (2).
> >
> > Tip: for high performance cases on local machine where you're sharing pages, you don't run
> > your serialization functions under your sharing abstraction. It's useless overhead.
> >
> > >
> > > The combined absence of 1 and 2 was (and still is) making hard for processes to communicate.
> >
> > No it wasn't.
> >
> > > It is curious that you are fully responsible for the absence of (1) in the Linux kernel.
> > >
> > > By the way, it is my firm opinion that you do not know how to properly design an operating system
> > > (... PID is just an integer, not a kernel object, and the integer value can be recycled? What an
> > > exquisitely crappy idea, for a PID to be what it is in Linux! typeof(PID)==just_int => idiocy).
> >
> > There are an endless number of firm believers in Linux's stupidity
> > and brokenness over the decades. You are in good company.
>
> It isn't an endless number.
Maybe so, but today it is N+1.
>
> > >
> > > > Yes, yes, "long mode" is a new mode bit, but at the same time you can see how it's
> > > > really using the same instruction decode logic, the same execution units, etc etc.
> > > > It's not two different front-ends, it's clearly one unified architecture.
> > >
> > > The success of the 64-bit "long mode" of x86 CPUs only proves that there are
> > > huge mistakes in operating system design and in programming language design.
> >
> > Non sequitur. Even if your above false assertions were true,
> > you have provided no logic to derive this from them.
>
> I don't care whether I convince you (personally) or not.
I care that you're polluting the forum with bullshit and insults of a highly respected poster here who actually knows something.
>
> > >
> > > > Yes, you could drop some legacy x86 stuff, but you can tell how integrated x86-64 is by simply
> > > > noting that the stuff you'd drop is actually totally independent of the new long mode.
> > >
> > > x86-64 solely exists because AMD outcompeted all mainstream OS developers and programming language
> > > designers. With the 64-bit address space AMD solved the memory limit problem in the large applications
> > > that were starting to appear around the year 2000. Programs consuming 300 MiB of memory are just too
> > > close to the 4 GiB limit of the 32-bit address space, and so 4 GiB starts to limit progress.
> >
> > What are you babbling about? 300MiB? Easily usable by a single process in standard 32-bit mode.
>
> You do not know how to read texts. The meaning of a text is always behind obvious contradictions. Intelligent
> people who understand complexity have no problems to clear the obvious contradictions and to devise appropriate
> generalizations and/or examples from their own experience in order to find the rationale.
So are you going to say exactly how you are going to arbitrarily redefine words such that
"Programs consuming 300 MiB of memory are just too close to the 4 GiB limit of the 32-bit
address space"
Is *not* a hilariously stupid falsehood?
>
> > OS developers
> > > and programming language designers (including the C programming language) misunderstood what was happening
> > > and failed to solve the coming problems before the CPU solved it. Basically, they failed to devise
> > > a way of efficiently splitting the coming memory intensive applications into multiple 32-bit processes
> >
> > No, they did not. This was actually done. See remap_file_pages(2), for example.
>
> There is no semantic difference between mmap(2) and remap_file_pages(2).
The example was to show that effort was made to support this broken model slightly more efficiently. So what is your point about semantic difference?
>
> > But it was done from necessity and Intel's IA64-driven artificial restriction on
> > extending the address space. NOT because it was the best technical thing to do.
> >
> > > - and that is why x86-64 appeared as-if it was the logical step to do.
> > >
> > > > It's basically
> > > > the same thing you might want to drop even if you never did long mode at all. The things you'd
> > > > likely want to drop are the old 16-bit modes, and some of the worst excesses dragged in by the
> > > > i286 in particular. But it may never happen, because it just isn't painful enough.
> > > >
> > > > And I really think that the whole "seamless integration" was the right thing to do.
> > >
> > > No wonder here. You (mis)designed the Linux kernel so there is
> > > no reason to believe that you could imagine a different world.
> >
> > You're a joke, quite frankly. I should not have bothered wasting my time to reply to you.
>
> The wasted time is your own problem.
>
> > You did not show even a faint glimmer of understanding, and literally everything you said above was wrong.
>
> The argument presented in my previous post is valid.
>
> > If you can point to an operating system which does these things fundamentally better, with
> > evidence; or even a concrete proposal of *exactly* how an application is restricted with
> > current OS, and *exactly* what steps can solve it, then do so now. If not, STFU.
>
> I don't see any reason to share my work with you. If the description in my previous
> post wasn't enough for you to reproduce the needed steps, that is your own problem.
>
> If you wanted to ask me how to implement some of the steps, you chose an inappropriate way of doing it.
>
> > I'm quite serious. You *do* realize that unmoderated forums
> > and mailing lists are literally full of crazies,
> > charlatans, and half-wits peddling their snake oil and offering exactly zero evidence or sound logic?
> > And that your ranting post makes you indistinguishable from them? So, no more handwaving or insults here.
> > Link to source code, or logically sound steps combined with link to numerical evidence.
>
> I refuse to give you access to my own work. If you do not believe that
> what I wrote is true, then don't believe it. It is your choice.
>
> In my opinion, the world isn't going to be a better place
> unless your style of writing and argumentation improve.
Stop posting, imbecile.
> anon (anon.delete@this.anon.com) on August 21, 2013 2:09 am wrote:
> > ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on August 20, 2013 11:29 pm wrote:
> > > 64-bit address space isn't a necessity.
> >
> > Yes it is, for the kernel, and for quite a few large applications,
> > ranging from databases, to hpc, to cad and media editing.
>
> You did not carefully read my post. The model I described does work if the computer has for example
> 32 GiB physical memory (which is 8x more than the 32-bit address space).
Wrong. You did not read my reply. I did not say your stupid model of splitting up apps and over complicating them due to lack of address space would not work. I said that the required kernel facilities that do not exist in your fantasy world, but have existed for decades in the real one, are not inhibiting this model from being implemented.
The fact is that the necessity does not come about because the kernel limits inter process communication and sharing. It is because it is not practical or economical to redesign hugely complex programs into a suboptimal form in order to accommodate for limited hardware.
The correct approach is to use the correct hardware design for the job.
> The applications you
> mentioned can be split into multiple 32-bit processes: Media editing can be very easily split
> into multiple 32-bit processes. If you put a two-stage application-level "page table" into a database
> application, you can easily divide it into multiple 32-bit processes/threads. Etc.
The applications I mentioned don't even need to be split. They can window into physical memory if needs be (this is what Oracle did).
I did never imply that was impossible, when I said 64-bit was a necessity (which it is).
>
> In other words: You are very impatient. Not because you are inherently stupid, but because you didn't
> want to spent the time needed to find the rationale behind my arguments. The several minutes you spent
> responding to my post clearly aren't enough for you to understand what I described in my post.
You should take your own advice, but in your case, you are inherently stupid.
>
> > Real users were hitting 32-bit x86 limits 10 years ago. Probably more.
>
> Yes. That is what I wrote. We were hitting the limits of the 32-bit address space.
Yep. Sucks for your argument, doesn't it?
>
> > > 32-bit address space is big enough for 99.9% of programs.
> >
> > "Most do not require it, therefore nobody requires it."
> >
> > See the logical fallacy?
>
> Yes. I saw it clearly while I was writing my post. It is curious
> that you considered worth your time to react to such a fallacy.
Of course you don't care for logic.
>
> > > In 99.9% programs, 64-bit address space has no performance advantage over a 32-bit address space.
> > >
> > > The non-existent things that AMD actually did exploit were:
> > >
> > > (1) The absence of an easy and safe way to do inter-process page mapping.
> >
> > Wrong. This exists in Linux and POSIX for ever.
>
> It only means that I do not agree with some parts of the POSIX model.
Which you fail to specify, of course.
>
> > > In particular it is the absence of
> > > the following programming pattern: 32-bit process X selects a page P from its address space and directly or
> > > indirectly tells the OS kernel to map the page P into the address space of the 32-bit process Y. The page P
> > > has the same 64-bit physical memory address, but its 32-bit virtual addresses in X and Y are different.
> >
> > You either fail to describe your programming pattern properly,
>
> I think it isn't necessary to describe it in greater length, due to multiple reasons.
I think that there is only one reason, and that is that you are a spectacular nincompoop.
>
> > or do not understand the concept
> > of a unix process. Because either 1) this is already trivially possible, or 2) it is idiotic.
> >
> > One process does not change the structure of another process address space.
> > This is simply not done, for good reason. Threads exist for this reason.
>
> The distinction between a Linux process and thread wasn't important enough for me to mention it in my post.
Your idiotic example is describing *the fundamental* difference between processes and threads. That is: threads of execution will either modify the address space of one another, or they will not.
>
> > On the other hand, you can trivially set up a communication mechanism between two processes and make them
> > do whatever you like. Process X can trivially tell process Y to perform some address space operation.
>
> If it is trivial, why aren't common Linux applications doing it?
Because your idea to split things into multiple processes in order to address more ram is stupid.
>
> > >
> > > (2) Complete lack of data serialization functions that
> > > would be built into mainstream programming languages.
> > > That is, the programming language needs to have a couple
> > > of builtin functions for transforming graphs of objects
> > > or structs into binary representation and for restoring
> > > such graphs from binary data. All that is needed are
> > > these two functions: bytes=save(x), y=load(bytes). I have
> > > implemented such functions in a programming language
> > > of my own, and the presence of such functions in the programming
> > > language makes a big difference in terms of
> > > communication between parts of a single program and in terms of communication between different programs.
> >
> > That's idiotic. There is no fundamental reason to put a data serialization protocol into a programming
> > language, and nothing preventing serialization functions from being used. Which they are. Widely.
>
> A fundamental reason preventing serialization functions from being used is:
> distance to the functions (ease of use from any point in a program).
What kind of nonsense is this?
>
> > >
> > > Case (1) obviously covers binary data only. For example, it can be used
> > > to send pixels to the X server. Secondly, it can be used by case (2).
> >
> > Tip: for high performance cases on local machine where you're sharing pages, you don't run
> > your serialization functions under your sharing abstraction. It's useless overhead.
> >
> > >
> > > The combined absence of 1 and 2 was (and still is) making hard for processes to communicate.
> >
> > No it wasn't.
> >
> > > It is curious that you are fully responsible for the absence of (1) in the Linux kernel.
> > >
> > > By the way, it is my firm opinion that you do not know how to properly design an operating system
> > > (... PID is just an integer, not a kernel object, and the integer value can be recycled? What an
> > > exquisitely crappy idea, for a PID to be what it is in Linux! typeof(PID)==just_int => idiocy).
> >
> > There are an endless number of firm believers in Linux's stupidity
> > and brokenness over the decades. You are in good company.
>
> It isn't an endless number.
Maybe so, but today it is N+1.
>
> > >
> > > > Yes, yes, "long mode" is a new mode bit, but at the same time you can see how it's
> > > > really using the same instruction decode logic, the same execution units, etc etc.
> > > > It's not two different front-ends, it's clearly one unified architecture.
> > >
> > > The success of the 64-bit "long mode" of x86 CPUs only proves that there are
> > > huge mistakes in operating system design and in programming language design.
> >
> > Non sequitur. Even if your above false assertions were true,
> > you have provided no logic to derive this from them.
>
> I don't care whether I convince you (personally) or not.
I care that you're polluting the forum with bullshit and insults of a highly respected poster here who actually knows something.
>
> > >
> > > > Yes, you could drop some legacy x86 stuff, but you can tell how integrated x86-64 is by simply
> > > > noting that the stuff you'd drop is actually totally independent of the new long mode.
> > >
> > > x86-64 solely exists because AMD outcompeted all mainstream OS developers and programming language
> > > designers. With the 64-bit address space AMD solved the memory limit problem in the large applications
> > > that were starting to appear around the year 2000. Programs consuming 300 MiB of memory are just too
> > > close to the 4 GiB limit of the 32-bit address space, and so 4 GiB starts to limit progress.
> >
> > What are you babbling about? 300MiB? Easily usable by a single process in standard 32-bit mode.
>
> You do not know how to read texts. The meaning of a text is always behind obvious contradictions. Intelligent
> people who understand complexity have no problems to clear the obvious contradictions and to devise appropriate
> generalizations and/or examples from their own experience in order to find the rationale.
So are you going to say exactly how you are going to arbitrarily redefine words such that
"Programs consuming 300 MiB of memory are just too close to the 4 GiB limit of the 32-bit
address space"
Is *not* a hilariously stupid falsehood?
>
> > OS developers
> > > and programming language designers (including the C programming language) misunderstood what was happening
> > > and failed to solve the coming problems before the CPU solved it. Basically, they failed to devise
> > > a way of efficiently splitting the coming memory intensive applications into multiple 32-bit processes
> >
> > No, they did not. This was actually done. See remap_file_pages(2), for example.
>
> There is no semantic difference between mmap(2) and remap_file_pages(2).
The example was to show that effort was made to support this broken model slightly more efficiently. So what is your point about semantic difference?
>
> > But it was done from necessity and Intel's IA64-driven artificial restriction on
> > extending the address space. NOT because it was the best technical thing to do.
> >
> > > - and that is why x86-64 appeared as-if it was the logical step to do.
> > >
> > > > It's basically
> > > > the same thing you might want to drop even if you never did long mode at all. The things you'd
> > > > likely want to drop are the old 16-bit modes, and some of the worst excesses dragged in by the
> > > > i286 in particular. But it may never happen, because it just isn't painful enough.
> > > >
> > > > And I really think that the whole "seamless integration" was the right thing to do.
> > >
> > > No wonder here. You (mis)designed the Linux kernel so there is
> > > no reason to believe that you could imagine a different world.
> >
> > You're a joke, quite frankly. I should not have bothered wasting my time to reply to you.
>
> The wasted time is your own problem.
>
> > You did not show even a faint glimmer of understanding, and literally everything you said above was wrong.
>
> The argument presented in my previous post is valid.
>
> > If you can point to an operating system which does these things fundamentally better, with
> > evidence; or even a concrete proposal of *exactly* how an application is restricted with
> > current OS, and *exactly* what steps can solve it, then do so now. If not, STFU.
>
> I don't see any reason to share my work with you. If the description in my previous
> post wasn't enough for you to reproduce the needed steps, that is your own problem.
>
> If you wanted to ask me how to implement some of the steps, you chose an inappropriate way of doing it.
>
> > I'm quite serious. You *do* realize that unmoderated forums
> > and mailing lists are literally full of crazies,
> > charlatans, and half-wits peddling their snake oil and offering exactly zero evidence or sound logic?
> > And that your ranting post makes you indistinguishable from them? So, no more handwaving or insults here.
> > Link to source code, or logically sound steps combined with link to numerical evidence.
>
> I refuse to give you access to my own work. If you do not believe that
> what I wrote is true, then don't believe it. It is your choice.
>
> In my opinion, the world isn't going to be a better place
> unless your style of writing and argumentation improve.
Stop posting, imbecile.
