Can extra processing threads help in this case?
in [MFC]
|
From: Peter Olcott on 25 Mar 2010 18:22 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:mbnnq5lojmk425f9p7aghukgcvnvqv9fio(a)4ax.com... > See below... > On Thu, 25 Mar 2010 14:09:06 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > > >>> **** >>> Rubbish. You told us you had something like 27,000 page >>> faults while you were loading >>> your data! And you have completley missed the point >>> here, >>> which is the page faults are >>> AMORTIZED over ALL processes! So if you have 8 >>> processes, it is like each page fault >> >>Nope, the 27,000 pages faults were just for my process. I >>don't care about page faults when the data is loaded. I >>want >>to (and apparently have) eliminate page faults during OCR >>recognition. > **** > Duh! Didn't we just tell you that memory-mapped files DO > THIS FOR YOU! But you have your > fixation that it doesn't work this way (and we know how it > DOES work, but you won't > listen), so nothing we can tell you seems to have any > impact. > **** >> >>> counts as 1/8 of a page fault. And they only happen >>> during the loading phase, which >>> doesn't change anything! >>> **** >>>> >>>>It continues to work (in practice) the way that I need >>>>it >>>>to >>>>work, and I have never seen it work according to Joe's >>>>theories. Whenever there is plenty of excess RAM (such >>>>as >>>>4 >>>>GB more than anything needs) there are no page-faults in >>>>my >>>>process. I even stressed this out a lot and had four >>>>processes taking 1.5 GB each (of my 8 GB) and still zero >>>>page faults in any of the four processes. >>> **** >>> I don't have theories. I am talking about practice. >>> You >>> talk about having "no" page >>> faults, but do you know if those pages have been written >>> to the paging file? No, you >>> don't. And with a MMF, you will quickly converge on the >>> same zero page faults; by what >> >>So if I end up at the same place, then it makes no sense >>to >>learn another way to end up at the same place. > **** > Hmmm. If I have two approaches that generate a million > dollars, and one generates a > million dollars and stops, and the other generates a > million dollars and continues to do > so, there is no reason to learn the second method, because > the first method and the second > method both generate a million dollars! > > What part of "scalability" did you fail to comprehend? > You are saying that if you have > one process, and one thread, and it generates N page > faults, and the other method > generates N page faults, then since N==N, there is nothing > to be gained by the second > method. > > But we have REPEATEDLY told you that if you have multiple > processes,, say K processes, > your method ALWAYS generates K*N page faults, and each > process uses B + N pages, and our > suggstion generates N page faults indpependent of K. Each > process uses EFFECTIVELY B + > N/p pages where p is the number of processes (the value N > is amortized over all > processes). .And in the single-process single-thread > case, it generates M page faults > where M < N. Is this so hard to comprehend? It involves > second-grade arithmetic. > joe > But I have said many times now that I will not scale by processes I will scale by threads, and these threads all share that same data so the benefit that you keep pushing about memory mapped files continues to be moot. I may actually scale by servers instead of processes or threads, because five single core servers cost half as much as one quad core server. > ***** > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 25 Mar 2010 18:27 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:1tnnq5tmhhkeb3hv0f8maucmu0ppds3757(a)4ax.com... > See below... > On Thu, 25 Mar 2010 14:10:48 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >>> And what did you miss about "scalability"? Oh, that;s >>> right, you will just throw more >>> hardware at it. And rely on your ISP to provide >>> load-balancing. Have you talked to them >>> about how they do load-balancing when you have multiple >>> servers? >>> joe >> >>My whole focus was to leverage memory to gain speed. > **** > If your only tools is a hammer, all your problems look > like nails. Guess what: we tried > to explain to you how to leverage memory to gain speed, > using a different perspective, but > you don't want to pay attention to us. Multithreaded > single process and > memory-mapped-file multiprocess BOTH leverage memory usage > to gain speed. This is the > consequence of deep understanding of reality. > joe > **** So I have been convinced for several days now that multi-threads could be a good idea. I still see no benefit of adding memory mapped files to this mix. You have explicitly failed to point out any incremental benefit that I get from memory mapped files over multiple threads sharing the same memory in the case where data remains resident in memory as my testing has shown that it does. (I will also test this on Linux). What you do instead is continue to insist that data does not remain resident in memory. I will test this in Linux very soon. >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Liviu on 25 Mar 2010 18:36 "Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote... > > I believe that your interpretation of "fault tolerance" is that a > catastrophic event could happen to your system and you application > would not lose *any* data. Is this the definition that you are using? Absent any catastrophic events, a system might still be called "fault tolerant" if it managed at least one successful run under controlled conditions on developer's machine, despite all faults with its design and implementation ;-) Liviu
From: Geoff on 25 Mar 2010 18:49 On Thu, 25 Mar 2010 10:25:21 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >Also I will not have four instances of the OCR code. I will >have a number of OCR threads that scales to the number of >CPU cores. Ah HA! Now we have a threaded FIFO queue process that scales to the number of cores, is fault tolerant, uses persistent storage, uses interprocess communication to communicate between processes, uses pthreads, uses MySQL for enhancing advertising claims, is patented using prior art algorithms and is 100% guaranteed to satisfy a 500 ms deadline on all transactions unless the FIFO is full whereupon we will have latency equal to the time it takes UPS to deliver a new server after we have achieved sufficient loading on the first iteration of the server using metrics yet to be verified as applicable. I am beginning to think "Peter Olcott" is an advanced AI bot along the lines of ELIZA that picks up buzz words in scanned text and echoes them back. I see. How does that make you feel? Is fault tolerant persistent storage more effective in FIFO or LIFO mode after writing our own std::vector implementation?
From: Peter Olcott on 25 Mar 2010 20:20
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:64onq5dabohqabp4htku20ajb8q96r06s1(a)4ax.com... > See below... > On Thu, 25 Mar 2010 10:12:56 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>message news:00rmq5hctllab7ursv8q64pq5eiv8s82ad(a)4ax.com... >>> See below... >>> On Thu, 25 Mar 2010 00:01:37 -0500, "Peter Olcott" >>> <NoSpam(a)OCR4Screen.com> wrote: >>> >>>> >>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>message >>>>news:rdqlq5dv2u8bh308se0td53rk7lqmv0bki(a)4ax.com... >>>>> Make sure the addresses are completely independent of >>>>> where the vector appears in memory. >>>>> >>>>> Given you have re-implemented std::vector (presumably >>>>> as >>>>> peter::vector) and you have done >>>>> all the good engineering you claim, this shouldn't >>>>> take >>>>> very much time at all. Then you >>>>> can use memory-mapped files, and share this massive >>>>> footprint across multiple processes, >>>>> so although you might have 1.5GB in each process, it >>>>> is >>>>> the SAME 1.5GB because every >>>>> process SHARES that same data with every other >>>>> process. >>>>> >>>>> Seriously, this is one of the exercises in my Systems >>>>> Programming course; we do it >>>>> Thursday afternoon. >>>>> joe >>>> >>>>But all that this does is make page faults quicker >>>>right? >>>>Any page faults at can only degrade my performance. >>> *** >>> Denser than depleted uranium. Fewer page faults, >>> quicker. >>> For an essay, please explain >>> in 500 words or less why I am right (it only requires >>> THINKING about the problem) and why >>> these page faults happen only ONCE even in a >>> multiprocess >>> usage! Compare to the ReadFile >>> solution. Compare and contrast the two approaches. >>> Talk >>> about storage allocation >>> bottlenecks. >>> >>> I'm sorry, but you keep missing the point. DId you >>> think >>> your approach has ZERO page >>> faults? You even told us it doesn't! >> >>I was making a conservative estimate, actual measurement >>indicated zero page faults after all data was loaded, even >>after waiting 12 hours. > *** > And a memory-mapped file would not show the same > performance? You know this HOW? > **** >> >>> Why do you think a memory-mapped file is going to >>> be different? Oh, I forgot, you don't WANT to >>> understand >>> how they work, or how paging >>> works! >> >>Not if testing continues to show that paging is not >>occurring. > **** > SCALABILITY! SCALABILITY! MAXIMIZE THROUGHPUT! MEET > 500MS PERFORMANCE GOALS! > SCALABILITY! > If there are no page faults without a memory mapped file and there are no page faults with a memory mapped file, then exactly and precisely what is the specific incremental benefit of a memory mapped file? (The performance and memory usage would have to be the same in both cases). I don't want a really quick way to load more data when needed, because there is no possible way that this could be nearly as fast as having the data already loaded. > Your method does not scale; our suggestions give you > scalability, maximize throughput, and > probably makes it possible to meet your wonderful 500ms > goal consistently. > joe Yet you have consistently, time after time, again and again never backed this up with reasoning. As soon as you back this up with verifiably correct reasoning, thenn (then and only then) will I agree. I absolutely and positively reject dogma as a source of truth. > > **** >> >>> joe >>> **** >>> >>> Joseph M. Newcomer [MVP] >>> email: newcomer(a)flounder.com >>> Web: http://www.flounder.com >>> MVP Tips: http://www.flounder.com/mvp_tips.htm >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |