I am doing a random file access to write log records in it. Later, I do access the log based on the log number. Using the log number I do calculate the offset of the record and directly access that. The function SetFilePointerEx is used to set the current location in the file and from there I can directly read the record.
The function expects the LARGE_INTEGER as parameter. How do I use LARGE_INTEGER for the SetFilePointerEx function? The req. notes says that the program will be targeted to 64 bit OS.
Assuming LARGE_INTEGER li;, just set li.QuadPart to the LONGLONG value you need for your file offset and use li for the offset argument in the call. Or did I miss something obvious.?
LARGE_INTEGER li, lo={0};
li.QuadPart = yourOffsetValue;
SetFilePointerEx(hFile, li, &lo, FILE_BEGIN);
Related
I'm trying to print to the file amount of microseconds:
high_resolution_clock::time_point t1 = high_resolution_clock::now();
high_resolution_clock::time_point t2 = high_resolution_clock::now();
auto duration1 = duration_cast<microseconds> (t2-t1).count();
fprintf(file, "%lu, %lu\n", dutation1, duration1);
In the file I can see the first column having some values around 2000 but
I get second column values always equal to zero. I wonder if I'm doing correct fprintf (the %lu parameter) and why does it print the second variable as zero in the file?
The count function returns a type called rep, which according to this std::duration reference is
an arithmetic type representing the number of ticks
Since you don't know the exact type, you can't really use any printf function to print the values, since if you use the wrong format you will have undefined behavior (which is very likely what you have here).
This will be easily solved if you use C++ streams instead, since the correct "output" operator << will automatically be selected to handle the type.
In kernel 2.4.37, there is a macro in page.h like this:
struct page *mem_map;
struct page *page;
#define VALID_PAGE(page) ((page - mem_map) < max_mapnr)
I know mem_map is an array of struct page, page is a struct, so what does page - mem_map mean?
It will compute the index of corresponding page in mem_map array means which number of page it is in mem_map array, let say it as pfn or page frame number for linux (linux assumes that mem_map array starts with 0th pfn to the max pfn) , adding a PHYS_PFN_OFFSET to pfn will give you the actual physical page frame in your memory map.
__page_to_pfn
max_mapnr is the limit of maximum number of mapped pages or maximum page frame number.
set_max_mapnr
I hope it clears your doubts.
Humm, I'm not sure but maybe a pointer adresses comparaison ?
I mean, if one of them is a array and it's not dereferenced the operations are apply on adresses I suppose.
Edit: (precision)
So, in this case I think this operation is for check if "page" is in range of the adresses array "mem_map".
We can represent like this: Graphic representation
Utility of Macro:
So, "mem_map" is adresses of the begin of array, suppose: 0x0...5.
The size of "mem_map"(max_mapnr) array is: 5.
We want to know if "page" adresses is in the range of "mem_map" array.
True Case:
Suppose "page" is in "mem_map", 2e element. We can suppose his adresses is something like: 0x0...7;
Now we do operation: ((0x0...7 - 0x0...5) < 5).
We obtain 2. So "page" adresse is in mem_map.
False Case:
Otherwise if "page" is out of the array (0x0...D): We the result will be 8. So, 8 is not less than "max_mapnr"(5). So this page is not in the "mem_map" array.
And if the adresses is bellow the array adresse (0x0...2):
The result of ((0x0...2 - 0x0...2)) will be a negative value. And in that case they comparaison with "max_mapnr"(unsigned long) is not possible.
I found this topic explain why better than me:
Signed/unsigned comparisons
So for resume:
You canno't do operations between negative(signed) and unsigned value in C cause he cast them automaticaly. In others terms, when you do (-3 - U_nbr), it's same if you do: (((unsigned)-3) - U_nbr). And in option, normaly if you compile with gcc -Wall flags, and you don't cast manually your value you will have an compilation Warning message.
For testing I tried to run this code:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void)
{
unsigned long test = 0x0000F;
unsigned long test2 = 0x0000A;
unsigned long weird = 0x00002;
char* pt1 = "This is first test string !";
char* pt2 = "This is a test string";
printf("Try to make operation on two unsigned long result must be 5: %lu\n", (test - test2));
printf("Try to make operation between unsigned long result must be negative, so he will be cast: %lu\n", (weird - test2));
printf("Let's try the same with real adresses: %lu\n", (pt2 - pt1));
printf("And this is what happens with negative value: %lu\n", (pt1 - pt2));
printf("For be sure, this is the lenght of string 1. %lu\n", strlen(pt1));
return (0);
}
The ouput is:
Try to make operation on two unsigned long result must be 5: 5
Try to make operation between unsigned long result must be negative, so he will be cast: 18446744073709551608
Let's try the same with real adresses: 28
And this is what happens with negative value: 18446744073709551588
For be sure, this is the lenght of string 1. 27
So, as we can see, the negative value is casted in Unsigned long and return a overflowed one. And if you make this comparaison with max_mapnr you will see he is "out of range".
Thank's to AnshuMan Gupta for the "weird case".
I have found some code in PyCXX that may be buggy.
Is it indeed a bug, and if so, what is the right way to fix it?
Here is the problem:
struct PythonClassInstance
{
PyObject_HEAD
ExtObjBase* m_pycxx_object;
}
:
{
:
table->tp_new = extension_object_new; // PyTypeObject
:
}
:
static PyObject* extension_object_new(
PyTypeObject* subtype, PyObject* args, PyObject* kwds )
{
PythonClassInstance* o = reinterpret_cast<PythonClassInstance *>
( subtype->tp_alloc(subtype,0) );
if( ! o )
return nullptr;
o->m_pycxx_object = nullptr;
PyObject* self = reinterpret_cast<PyObject* >( o );
return self;
}
Now PyObject_HEAD expands to "PyObject ob_base;", so clearly PythonClassInstance trivially extends PyObject to contain an extra pointer (which will point to PyCXX's representation for this PyObject)
tp_alloc allocates memory for storing a PyObject
The code then typecasts this pointer to a PythonClassInstance, laying claim to an extra 4(or 8?) bytes that it does not own!
And then it sets this extra memory to 0.
This looks very dangerous, and I'm surprised the bug has gone unnoticed. The risk is that some future object will get placed in this location (that is meant to be storing the ExtObjBase*).
How to fix it?
PythonClassInstance foo{};
PyObject* tmp = subtype->tp_alloc(subtype,0);
// !!! memcpy sizeof(PyObject) bytes starting from location tmp into location (void*)foo
But I think now maybe I need to release tmp, and I don't think I should be playing with memory directly like this. I feel like it could be jeopardising Python's memory management/garbage collection inbuilt machinery.
The other option is maybe I can persuade tp_alloc to allocate 4 extra bytes (or is it 8 now; enough for a pointer) bypassing in 1 instead of 0.
Documentation says this second parameter is "Py_ssize_t nitems" and:
If the type’s tp_itemsize is non-zero, the object’s ob_size field
should be initialized to nitems and the length of the allocated memory
block should be tp_basicsize + nitemstp_itemsize, rounded up to a
multiple of sizeof(void); otherwise, nitems is not used and the
length of the block should be tp_basicsize.
So it looks like I should be setting:
table->tp_itemsize = sizeof(void*);
:
PyObject* tmp = subtype->tp_alloc(subtype,1);
EDIT: just tried this and it causes a crash
But then the documentation goes on to say:
Do not use this function to do any other instance initialization, not
even to allocate additional memory; that should be done by tp_new.
Now I'm not sure whether this code belongs in tp_new or tp_init.
Related:
Passing arguments to tp_new and tp_init from subtypes in Python C API
Python C-API Object Allocation
The code is correct.
As long as the PyTypeObject for the extension object is properly initialized it should work.
The base class tp_alloc receives subtype so it should know how much memory to allocate by checking the tp_basicsize member.
This is a common Python C/API pattern as demonstrated int the tutorial.
Actually this is a (minor/harmless) bug in PyCXX
SO would like to convert this answer to a comment, which makes no sense I can't awarded the green tick of completion so I comment. So I have to ramble in order to qualify it. blerh.
I can't seem to get a reliable timestamp using winapi functions. For example:
int main(int argc, char *argv[])
{
HANDLE file;
BY_HANDLE_FILE_INFORMATION finfo;
SYSTEMTIME systime;
file = CreateFile("test.txt",GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
GetFileInformationByHandle(file,&finfo);
FileTimeToSystemTime(&finfo.ftLastWriteTime, &systime);
printf(" %s %02d:%02d:%02d %d/%d/%d\n", "test.txt", systime.wHour,systime.wMinute,systime.wSecond,systime.wDay,systime.wMonth,systime.wYear);
}
gives non-sense on all my files like:
test.txt 00:03:30 33/5/3
wDay seems to have values outside of range 1-31 and the times and dates are totally wrong. All other values in the BY_HANDLE_FILE_INFORMATION like name and size are correct, and in I full code I check for errors from all functions, but they all return passed. Anyone know what I am doing wrong?
I think the problem is your use of filesize.QuadPart. Try removing that from both the format string and the argument list, and see if it works.
If that helps, then look up the correct format string to use for a 64-bit quantity in printf().
How can you measure the amount of time a function will take to execute?
This is a relatively short function and the execution time would probably be in the millisecond range.
This particular question relates to an embedded system, programmed in C or C++.
The best way to do that on an embedded system is to set an external hardware pin when you enter the function and clear it when you leave the function. This is done preferably with a little assembly instruction so you don't skew your results too much.
Edit: One of the benefits is that you can do it in your actual application and you don't need any special test code. External debug pins like that are (should be!) standard practice for every embedded system.
There are three potential solutions:
Hardware Solution:
Use a free output pin on the processor and hook an oscilloscope or logic analyzer to the pin. Initialize the pin to a low state, just before calling the function you want to measure, assert the pin to a high state and just after returning from the function, deassert the pin.
*io_pin = 1;
myfunc();
*io_pin = 0;
Bookworm solution:
If the function is fairly small, and you can manage the disassembled code, you can crack open the processor architecture databook and count the cycles it will take the processor to execute every instructions. This will give you the number of cycles required.
Time = # cycles * Processor Clock Rate / Clock ticks per instructions
This is easier to do for smaller functions, or code written in assembler (for a PIC microcontroller for example)
Timestamp counter solution:
Some processors have a timestamp counter which increments at a rapid rate (every few processor clock ticks). Simply read the timestamp before and after the function.
This will give you the elapsed time, but beware that you might have to deal with the counter rollover.
Invoke it in a loop with a ton of invocations, then divide by the number of invocations to get the average time.
so:
// begin timing
for (int i = 0; i < 10000; i++) {
invokeFunction();
}
// end time
// divide by 10000 to get actual time.
if you're using linux, you can time a program's runtime by typing in the command line:
time [funtion_name]
if you run only the function in main() (assuming C++), the rest of the app's time should be negligible.
I repeat the function call a lot of times (millions) but also employ the following method to discount the loop overhead:
start = getTicks();
repeat n times {
myFunction();
myFunction();
}
lap = getTicks();
repeat n times {
myFunction();
}
finish = getTicks();
// overhead + function + function
elapsed1 = lap - start;
// overhead + function
elapsed2 = finish - lap;
// overhead + function + function - overhead - function = function
ntimes = elapsed1 - elapsed2;
once = ntimes / n; // Average time it took for one function call, sans loop overhead
Instead of calling function() twice in the first loop and once in the second loop, you could just call it once in the first loop and don't call it at all (i.e. empty loop) in the second, however the empty loop could be optimized out by the compiler, giving you negative timing results :)
start_time = timer
function()
exec_time = timer - start_time
Windows XP/NT Embedded or Windows CE/Mobile
You an use the QueryPerformanceCounter() to get the value of a VERY FAST counter before and after your function. Then you substract those 64-bits values and get a delta "ticks". Using QueryPerformanceCounterFrequency() you can convert the "delta ticks" to an actual time unit. You can refer to MSDN documentation about those WIN32 calls.
Other embedded systems
Without operating systems or with only basic OSes you will have to:
program one of the internal CPU timers to run and count freely.
configure it to generate an interrupt when the timer overflows, and in this interrupt routine increment a "carry" variable (this is so you can actually measure time longer than the resolution of the timer chosen).
before your function you save BOTH the "carry" value and the value of the CPU register holding the running ticks for the counting timer you configured.
same after your function
substract them to get a delta counter tick.
from there it is just a matter of knowing how long a tick means on your CPU/Hardware given the external clock and the de-multiplication you configured while setting up your timer. You multiply that "tick length" by the "delta ticks" you just got.
VERY IMPORTANT Do not forget to disable before and restore interrupts after getting those timer values (bot the carry and the register value) otherwise you risk saving incorrect values.
NOTES
This is very fast because it is only a few assembly instructions to disable interrupts, save two integer values and re-enable interrupts. The actual substraction and conversion to real time units occurs OUTSIDE the zone of time measurement, that is AFTER your function.
You may wish to put that code into a function to reuse that code all around but it may slow things a bit because of the function call and the pushing of all the registers to the stack, plus the parameters, then popping them again. In an embedded system this may be significant. It may be better then in C to use MACROS instead or write your own assembly routine saving/restoring only relevant registers.
Depends on your embedded platform and what type of timing you are looking for. For embedded Linux, there are several ways you can accomplish. If you wish to measure the amout of CPU time used by your function, you can do the following:
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#define SEC_TO_NSEC(s) ((s) * 1000 * 1000 * 1000)
int work_function(int c) {
// do some work here
int i, j;
int foo = 0;
for (i = 0; i < 1000; i++) {
for (j = 0; j < 1000; j++) {
for ^= i + j;
}
}
}
int main(int argc, char *argv[]) {
struct timespec pre;
struct timespec post;
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &pre);
work_function(0);
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &post);
printf("time %d\n",
(SEC_TO_NSEC(post.tv_sec) + post.tv_nsec) -
(SEC_TO_NSEC(pre.tv_sec) + pre.tv_nsec));
return 0;
}
You will need to link this with the realtime library, just use the following to compile your code:
gcc -o test test.c -lrt
You may also want to read the man page on clock_gettime there is some issues with running this code on SMP based system that could invalidate you testing. You could use something like sched_setaffinity() or the command line cpuset to force the code on only one core.
If you are looking to measure user and system time, then you could use the times(NULL) which returns something like a jiffies. Or you can change the parameter for clock_gettime() from CLOCK_THREAD_CPUTIME_ID to CLOCK_MONOTONIC...but be careful of wrap around with CLOCK_MONOTONIC.
For other platforms, you are on your own.
Drew
I always implement an interrupt driven ticker routine. This then updates a counter that counts the number of milliseconds since start up. This counter is then accessed with a GetTickCount() function.
Example:
#define TICK_INTERVAL 1 // milliseconds between ticker interrupts
static unsigned long tickCounter;
interrupt ticker (void)
{
tickCounter += TICK_INTERVAL;
...
}
unsigned in GetTickCount(void)
{
return tickCounter;
}
In your code you would time the code as follows:
int function(void)
{
unsigned long time = GetTickCount();
do something ...
printf("Time is %ld", GetTickCount() - ticks);
}
In OS X terminal (and probably Unix, too), use "time":
time python function.py
If the code is .Net, use the stopwatch class (.net 2.0+) NOT DateTime.Now. DateTime.Now isn't updated accurately enough and will give you crazy results
If you're looking for sub-millisecond resolution, try one of these timing methods. They'll all get you resolution in at least the tens or hundreds of microseconds:
If it's embedded Linux, look at Linux timers:
http://linux.die.net/man/3/clock_gettime
Embedded Java, look at nanoTime(), though I'm not sure this is in the embedded edition:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#nanoTime()
If you want to get at the hardware counters, try PAPI:
http://icl.cs.utk.edu/papi/
Otherwise you can always go to assembler. You could look at the PAPI source for your architecture if you need some help with this.