Can extra processing threads help in this case?
in [MFC]
|
From: Oliver Regenfelder on 24 Mar 2010 07:00 Hello, Hector Santos wrote: > Also, you had a line: > > num = data[num] > > you were not referencing the entire spectrum of your memory allocation, > just one element. He is doing some state machine. Therefore his array is just some kind of transition table, data[i] defines where you have to go to starting from i. Therefore his num = data[num] somewhat represents walking through the DFA (somewhat because this way each state only has one follower state, and you would be better of reorganizing them). Best regards, Oliver
From: Oliver Regenfelder on 24 Mar 2010 07:08 Hello, Just some 64bit, C++ comments. Peter Olcott wrote: > #include <stdio.h> #include <cstdio> > #include <stdlib.h> #include <cstdlib> > #include <vector> > #include <time.h> #include <ctime> It is supposed to be C++ after all. > #define uint32 unsigned int typedef unsigned int uint32; > const uint32 repeat = 100; > const uint32 size = 524288000 / 4; > std::vector<uint32> Data; > > > > void Process() { > clock_t finish; > clock_t start = clock(); > double duration; > uint32 num; > for (uint32 r = 0; r < repeat; r++) > for (uint32 i = 0; i < size; i++) > num = Data[num]; This one is subtly bad. The proper type to index arrays is size_t. Especially as you will be running this on 64bit machines, and on windows64 int is still 32 bit as far as I remeber. Therefore make it a habit of indexing arrays with size_t. Because that array bigger than 4 GB will come and haunt you sooner or later. Also you are thinking about doing it on Windows, *nix, mac. In this case you can't rely on an int being able to index arrays of any possible size. > int main() { > printf("Size in bytes--->%d\n", size * 4); I would do: printf("Size in bytes--->%d\n", static_cast<size_t>(size) * 4); Otherwise you might be upset when size is above 1G. > Data.reserve(size); > for (int N = 0; N < size; N++) > Data.push_back(rand() % size); Again use size_t for indexing. Best regards, Oliver
From: Oliver Regenfelder on 24 Mar 2010 07:10 Hello Peter, Peter Olcott wrote: > If I was going to do it for real it would be one large > single std::vector of std::vectors shared across multiple > threads. I really don't want to deal with Virtual Memory > issues at all. I want to do everything that I reasonably can > to make them all moot. This may eventually require a > real-time OS. So you are using a std::vector of std::vectors inside your application? Somehting like: std::vector<std::vector<int> > Best Regards, Oliver
From: Peter Olcott on 24 Mar 2010 11:01 "Oliver Regenfelder" <oliver.regenfelder(a)gmx.at> wrote in message news:3aca2$4ba9eccc$547743c7$7677(a)news.inode.at... > Hello, > > Peter Olcott wrote: >> For all practical purposes virtual memory is not being >> used (meaning that its use is not impacting performance) >> whenever > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> zero or very few page faults are occurring. > > It think the underlined statement marks some part of the > problem. > In my opinion both of you are somewhat on the same point > of view > regarding virtual memory "usage" but you phrase your > insights > differently. > > I think that your(peter) wording is a bit missleading. You > represent the > fact that virual memory has no impact with the words "it > is not used" > which formally is wrong and that is one thing that offends > Hector. > > Could we agree to say that "virtual memory is used but > does not > show any impacts?" or better "virtual memory is used but > paging > does not occure". Those two statements better describe > what is > going on. > > Best regards, > > Oliver Yes you have this correctly.
From: Peter Olcott on 24 Mar 2010 11:07
"Oliver Regenfelder" <oliver.regenfelder(a)gmx.at> wrote in message news:bd8aa$4ba9f2af$547743c7$24260(a)news.inode.at... > Hello, > > Just some 64bit, C++ comments. > > Peter Olcott wrote: >> #include <stdio.h> > > #include <cstdio> > >> #include <stdlib.h> > > #include <cstdlib> > >> #include <vector> >> #include <time.h> > > #include <ctime> > > It is supposed to be C++ after all. > >> #define uint32 unsigned int > > typedef unsigned int uint32; > >> const uint32 repeat = 100; >> const uint32 size = 524288000 / 4; >> std::vector<uint32> Data; >> >> >> >> void Process() { >> clock_t finish; >> clock_t start = clock(); >> double duration; >> uint32 num; >> for (uint32 r = 0; r < repeat; r++) > >> for (uint32 i = 0; i < size; i++) >> num = Data[num]; > > This one is subtly bad. The proper type to index arrays is > size_t. > Especially as you will be running this on 64bit machines, > and on > windows64 int is still 32 bit as far as I remeber. > Therefore make > it a habit of indexing arrays with size_t. Because that > array > bigger than 4 GB will come and haunt you sooner or later. > > Also you are thinking about doing it on Windows, *nix, > mac. In this > case you can't rely on an int being able to index arrays > of any > possible size. > >> int main() { >> printf("Size in bytes--->%d\n", size * 4); > > I would do: > printf("Size in bytes--->%d\n", > static_cast<size_t>(size) * 4); > > Otherwise you might be upset when size is above 1G. > >> Data.reserve(size); >> for (int N = 0; N < size; N++) >> Data.push_back(rand() % size); > > Again use size_t for indexing. > > Best regards, > > Oliver It appears that your suggestions would be better form. |