Hi, Mian, FastBit tries to keep the bit vector on disk as much as possible, and only read them into memory when needed. The process of reading them into memory is called activation. Since your bitmaps are already in memory, there is no need to activate anything -- they have been activated already.
I will see if I can clarify the doxygen documentation a little bit.. John On 10/24/2009 12:20 AM, Mian Lu wrote: > Hi John: > > Thanks for your nice answers very much. I have a further question and hope > you can give me some suggestions. Following your advice, I am trying to > use sumBits or addBits to sum multiple bit vectors (since they are static > functions, I just separated them from the index class). However it looks > like does not work. Your comments said we need to "activate" the > appropriate "set" or explicitly give the activation. I did not quite > understand here. I tried to read your code, this activation looks like to > read data from a resource management? Actually, my target is very simple, > I have multiple in-memory bit vectors already stored in bts, then I only > want to perform the sum on these in-memory bit vectors. I really > appreciate if you can give me some suggestions. Thanks in advance. > > Regards, > Mian > > >> Hi, Mian, >> >> The two timing values are printed from two timing functions. They are >> about the same time period. The CPU seconds is measured function >> clock (or a similar function depending on system). This measurement >> is based on a sampling performed by CPU, therefore reflects how long >> the program is in the CPU, hence the name. The elapsed time is simply >> from the wall-clock time from the begin to the end of the time period. >> It is measured by gettimeofday (or a similar function if not >> available). The elapsed time can also be viewed as the real time (or >> total time). The difference between elapsed time and the CPU time >> can be regarded as the I/O time, however, this is not exactly accurate >> since the I/O operations also require CPU time. >> >> Typically gettimeofday returns a value that is of higher precision >> than that returned by the function clock. In some cases, this can >> cause the elapsed time to appear smaller than the CPU time. This is >> simply a precision problem. Another way that CPU time can appear >> larger than the elapsed time is when running the program with multiple >> threads. >> >> For relatively small test datasets, most of the OSes can cache the >> content of the files being used and therefore significantly diminish >> the differences between the CPU time and the elapsed time. In many of >> our timing measurements, we explicitly unmount the file system before >> each query to make sure nothing is cached. The time we report in our >> publications are usually the elapsed time, unless we are specifically >> comparing CPU time. >> >> Hope this helps. >> >> John >> >> >> On 10/22/2009 9:36 PM, Mian Lu wrote: >>> Hi John: >>> >>> I want to confirm a question about the time measurements in the Fastbit. >>> I >>> notice that after a query done, there are outputs: took X CPU seconds, Y >>> elapsed seconds. Then the X is the in-memory processing time, right? >>> Therefore the I/O access time actually is (Y-X) seconds, am I right? >>> Thanks in advance. >>> >>> Regards, >>> Mian >>> > > _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
