By: Michael S (already5chosen.delete@this.yahoo.com), August 21, 2013 2:13 pm
Room: Moderated Discussions
Carlie Coats (coats.delete@this.baronams.com) on August 21, 2013 12:25 pm wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on August 21, 2013 7:15 am wrote:
> > Carlie Coats (coats.delete@this.baronams.com) on August 21, 2013 6:31 am wrote:
> > > u269b (0xe2.0x9a.0x9b.delete@this.gmail.com) on August 21, 2013 4:12 am wrote:
> > > [snip...]
> > > > 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).
> > >
> > > Does *NOT* work if you need a multi-gigabyte stack (as some GIS
> > > algorithms do),
> >
> > Do you use the word 'stack' as synonym of LIFO, or for something else?
> >
> > If the former, then I don't understand how it could be true.
> > LIFO is one of those structures for which PAE windowing should work very well. Even when, for some reason,
> > you can't map the hot spot into your address space, with LIFO you always can fill/spill into paging pool.
> > For correctly chosen low/high water marks, the overhead of fill/spill process should be very small.
> >
> > > unless you program the whole thing by yourself
> > > using disk to emulate the stack, and increasing run-times by
> > > several orders of magnitude.
> >
> > It's seems, here you are describing the situation in which you were
> > running out physical memory rather than out of address space.
>
> Works perfectly well on my desktop, with 24GB RAM and
> a 64-bit OS: for 5000x8000-sized problem, it uses about
> 12GB of stack to do "cumulative drained area" calculations.
>
> It is hard to believe that you are so clueless as to
> fail to know that emulating 12GB of stack by hand with
> scratch disk-files won't be at least 1000 times slower
> than using a real RAM-based stack.
>
> And in case you never learned, emulating straightforward
> data structures "by hand" in terms of clumsy tools is
> either idiotic or for the truly desperate. (I'll admit
> I *would* be truly desperate if my boss asked me to do
> 100000x100000-sized problems).
>
> Do you write large programs in machine-code, too?
> The purpose of a compiler is to do that work for you.
>
>
O.k. After thinking a little I figured out what you mean. Stack, the place where compiler keeps automatic variables.
Took time to understand, because, except for recursion, people rarely use more than few MBs of it.
Indeed, for huge program stack, PAE is a non-solution. The problem, in that case, is similar to problem with big randomly accessed arrays, in which case PAE also does not work.
I still didn't understand why, instead of explaining what you mean in civilized manner, you started name calling. That's certainly not what I expected from you, based on past experience.
> Michael S (already5chosen.delete@this.yahoo.com) on August 21, 2013 7:15 am wrote:
> > Carlie Coats (coats.delete@this.baronams.com) on August 21, 2013 6:31 am wrote:
> > > u269b (0xe2.0x9a.0x9b.delete@this.gmail.com) on August 21, 2013 4:12 am wrote:
> > > [snip...]
> > > > 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).
> > >
> > > Does *NOT* work if you need a multi-gigabyte stack (as some GIS
> > > algorithms do),
> >
> > Do you use the word 'stack' as synonym of LIFO, or for something else?
> >
> > If the former, then I don't understand how it could be true.
> > LIFO is one of those structures for which PAE windowing should work very well. Even when, for some reason,
> > you can't map the hot spot into your address space, with LIFO you always can fill/spill into paging pool.
> > For correctly chosen low/high water marks, the overhead of fill/spill process should be very small.
> >
> > > unless you program the whole thing by yourself
> > > using disk to emulate the stack, and increasing run-times by
> > > several orders of magnitude.
> >
> > It's seems, here you are describing the situation in which you were
> > running out physical memory rather than out of address space.
>
> Works perfectly well on my desktop, with 24GB RAM and
> a 64-bit OS: for 5000x8000-sized problem, it uses about
> 12GB of stack to do "cumulative drained area" calculations.
>
> It is hard to believe that you are so clueless as to
> fail to know that emulating 12GB of stack by hand with
> scratch disk-files won't be at least 1000 times slower
> than using a real RAM-based stack.
>
> And in case you never learned, emulating straightforward
> data structures "by hand" in terms of clumsy tools is
> either idiotic or for the truly desperate. (I'll admit
> I *would* be truly desperate if my boss asked me to do
> 100000x100000-sized problems).
>
> Do you write large programs in machine-code, too?
> The purpose of a compiler is to do that work for you.
>
>
O.k. After thinking a little I figured out what you mean. Stack, the place where compiler keeps automatic variables.
Took time to understand, because, except for recursion, people rarely use more than few MBs of it.
Indeed, for huge program stack, PAE is a non-solution. The problem, in that case, is similar to problem with big randomly accessed arrays, in which case PAE also does not work.
I still didn't understand why, instead of explaining what you mean in civilized manner, you started name calling. That's certainly not what I expected from you, based on past experience.