Can extra processing threads help in this case?
in [MFC]
|
From: Pete Delgado on 25 Mar 2010 13:44 "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message news:EqmdnZkWypVi7DbWnZ2dnUVZ_rednZ2d(a)giganews.com... > (By fault tolerance I mean yank the power plug from the wall and when the > machine is re-started it (as much as possible) picks up right where it > left off) ....take a look at transactional NTFS. http://msdn.microsoft.com/en-us/library/aa365738(VS.85).aspx -Pete
From: Pete Delgado on 25 Mar 2010 13:58 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:dlnlq5pok9nbsc35uaedbot0m18btno5ti(a)4ax.com... >A multithreaded FIFO queue would make more sense; less chance of priority >inversion > effects. An I/O Completion Port makes a wonderful multithreaded FIFO > queue with > practically no effort! > joe But Joe, that would require him to read a 1000+ page book like Jeffery Richter's "Programming Server-Side Applications for Windows 2000" to understand what an IOCP is and how to use one effectively. Mr. Olcott has already stated that he doesn't have the time to do that!!! ;-) BTW: This whole thread reminds me of another couple of great books: Code Complete and Rapid Development by by Steve McConnell. Based upon his writings in this thread, Mr. Olcott is making some classic mistakes. Of course, again, both books I believe are 1,000+ pages! -Pete
From: Pete Delgado on 25 Mar 2010 14:02 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OOcyQDBzKHA.5288(a)TK2MSFTNGP05.phx.gbl... > Now you screwed up MONGOOSE, now you have 4 competition SOCKET servers on > PORT 80 and thats not possible on a single machine. You can only have 1 > PORT 80 HTTP SERVICE - NOT FOUR!! Oh Hector... please don't lie to Mr. Olcott!!! He most certainly can have 4 servers on port 80! Of course, he'd have to place an additional three network adapters in his machine and configure them, but after all it's a MONSTER machine isn't it??? <grin> -Pete
From: Peter Olcott on 25 Mar 2010 15:09 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:gqtmq59rviu93estk2bil8063o30h47gfh(a)4ax.com... > See below... > On Thu, 25 Mar 2010 08:57:59 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Ismo Salonen" <ismo(a)codeit.fi> wrote in message >>news:OjTbBi$yKHA.5332(a)TK2MSFTNGP02.phx.gbl... >>> Peter Olcott 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. >>>> >>> >>> just my two cents : >>> >>> memory mapped files are paged in to process memory when >>> the page is 1st time referenced (read or written). This >>> is >>> pagefault mechanism. >>> It is the most efficient way accessing data. Reading >>> memory by ReadFile() or others in that family are slower >>> (well ReadFile directly you buffers would result quite >>> similar performance bause it use the paging mechanism). >>> The pagefault mechanism must be quite optimized as it is >>> the basis for modern operating systems ( windows, linux >>> etc ). The inner workings are quite delicate and I >>> highly >>> suspect you can no way outperform it. >>> >>> It seems that you have plausible product idea but you >>> lack >>> the knowledge >>> how operating system works. Have you read the articles >>> others have >> >>One thing that I know is that a process with page faults >>is >>slower than a process without page faults everything else >>being equal. > **** > 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. > 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. > mystical method do you infer that these page faults are > repeated each time the page is > accessed, or are duplicated in each process? So how does > this differ from your current > implementation? The timing of the page faults is > different, but you will have at least > as many, and more likely fewer, using a MMF. But that's > assuming you are willing to learn > something new, which you've stated explicitly is not on > your agenda. "Make everything > better, but don't make me learn something new" I think > summarizes pretty accurately what > you've told us. > joe > > **** >> > 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 15:10
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:o6umq5d5qknp281l6s5ch1102adqq99908(a)4ax.com... > See below... > On Thu, 25 Mar 2010 09:02:19 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Oliver Regenfelder" <oliver.regenfelder(a)gmx.at> wrote in >>message >>news:3b7af$4bab373b$547743c7$31073(a)news.inode.at... >>> Hello, >>> >>> Peter Olcott wrote: >>>>> 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. >>> >>> It also reduces overall memory usage as stated earlier. >> >>I don't care about that at all. The machine will be a >>dedicated server that has the single purpose of running my >>process. > **** > 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. > > **** >> >>> >>> Say you have 4 processes (not threads!) then each of the >>> 4 >>> processes has its own address space. So if you need the >>> same >>> data in each process the simple thing is >>> 1) Generate an array or something >>> 2) Load precalculated data from file >>> >>> The problem is, that this way, each process has his >>> independend >>> copy of the data and you would use 4*data_size memory. >>> >>> Now if you use memory mapped files, then each process >>> would do >>> the following: >>> 1) Memory map the file[1]. >> >>Why not just have a single read only std::vector with >>multiple threads reading it? >> >>> >>> If you do this in each process then the OS will do its >>> magic and >>> recognize that the same file is mapped into memory 4 >>> times >>> and only >>> keep one physical copy of the file in memory. Thus you >>> only use >>> 1*data_size of memory. >>> >>> [1]: You somewhere mentioned something about OS >>> independence so >>> have a look at www.boost.org. The interprocess library >>> contains >>> the memory mapping code. You might also want to consider >>> it for >>> your threading in case the software shall not only run >>> on >>> Windows. >> >>If I can eliminate page faults then a thing that makes >>page >>faults quick is still moot, and not worth any learning >>curve. >> >>> >>> >>> Best regards, >>> >>> Oliver >>> >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |