With OpenMP 4 you can use a set of environment variables, like OMP_PROC_BIND or OMP_PLACES.
Are these variables used during compile-time or run-time? Let's say I have to do some experiments changing these values, do I have to recompile the program each time to apply them? Or just re-run it?
Note: it is difficult to me to test this, because at the moment I don't have the possibility to recompile my test program.
Environment variables affect the execution at run-time. You don't need to recompile the program. However, you should not modify the variables after the application was started.
Related
I need to hold a specific value (a string, to be exact) throughout the lifetime of a single WinDbg session.
The reason for that, is that I need to address this variable in a few places throughout the lifetime of the WinDbg session (through .if statements, to be exact), and I want it to be defined at the startup of the session - using an argument that'll be passed. It can't be undefined or disposed - I must be able to address it in any point in the debugging session, and of course I don't want to risk that it might be redefined.
I was thinking of using a file for that purpose, or a shared memory, but I much prefer to solve this using WinDbg scripting.
If it's possible, it's obviously a much more elegant solution.
I've done some reading online on this matter and the issue is that I couldn't find a reference where the differences between Aliases (defined by an aS command) and User-Defined Pseudo-Registers (the registers in the range $t0..$t19, which are accessed by using the r command) were described. I couldn't find really understand the use cases for each.
The seemed to me Aliases is the better option, due to the fact that they can be named, in contrast to User-Defined Pseudo-Registers which have set names (wasn't sure regarding how to pick the "right" registered, to minimize possible collisions with other scripts which might use it, or is there any difference at all).
Am I missing something here?
Which should I use in this case, or are they both unsuitable for this situation?
Why is the function compose defined in the interpreter csi and not in the compiler csc? I know I can easily define it by myself, but I was just wondering why there is such a difference.
The compose procedure is from the unit data-structures (see the manual or API docs). You can load it by typing (use data-structures).
As to why it's available in csi and not in csc by default is a bit of a hairy implementation detail; the csi interpreter simply needs to load a few modules itself in order to provide an interpreter environment. Due to the way it's implemented, everything that's loaded by csi also becomes available at the top-level. In CHICKEN 5, this situation has improved quite a bit and the interpreter starts with a clean top-level environment.
So what this means in practice is that you should always explicitly (use) all modules that your program needs, to ensure that it works in compiled mode as well as interpreted mode. Instead of putting your program at the top-level environment, you can also wrap your entire program inside a module. Modules always have a completely clean environment, so there will be no difference when you compile it versus when you interpret it.
In OpenMP, when you do not specify any loop iteration policy (in the code pragmas or through environment variable OMP_SCHEDULE), the specs (section 2.3.2) clearly state that the default loop iteration policy is implementation-defined and implementations may or may not expose it.
Is there a workaround to get this policy ? To be explicit, I would like to get the value of the internal control variable def-sched-var defined in the specs.
I am using GCC 4.9 with OpenMP 4.0 on a POWER8 architecture.
First of all, I never saw any implementation whose default type of scheduling was something else than static, but this doesn't mean all of them do use static as default.
However, from your comment, I deduct that you want to establish a correlation between the performance of the code and the type of scheduling that is used.
You have the possibility of running the code with various types of scheduling (namely static, dynamic and guided). This will tell you how the performance varies as a function of the scheduling policy. Maybe this will tell you something right away, but I would try different things, such as looking at every parallel loop and measure its performance. Post the main loops so we can tell you if there is something else going on.
Put simply, I doubt that changing the type of scheduling will solve bad performance that fast.
Are there any languages with possibility of declaring global assertions - that is assertion that should hold during the whole program execution. So that it would be possible to write something like:
global assert (-10 < speed < 10);
and this assertion will be checked every time speed changes state?
eiffel supports all different contracts: precondition, postcondition, invariant... you may want to use that.
on the other hand, why do you have a global variable? why don't you create a class which modifies the speed. doing so, you can easily check your condition every time the value changes.
I'm not aware of any languages that truly do such a thing, and I would doubt that there exist any since it is something that is rather hard to implement and at the same time not something that a lot of people need.
It is often better to simply assert that the inputs are valid and modifications are only done when allowed and in a defined, sane way. This concludes the need of "global asserts".
You can get this effect "through the backdoor" in several ways, though none is truly elegant, and two are rather system-dependent:
If your language allows operator overloading (such as e.g. C++), you can make a class that overloads any operator which modifies the value. It is considerable work, but on the other hand trivial, to do the assertions in there.
On pretty much every system, you can change the protection of memory pages that belong to your process. You could put the variable (and any other variables that you want to assert) separately and set the page to readonly. This will cause a segmentation fault when the value is written to, which you can catch (and verify that the assertion is true). Windows even makes this explicitly available via "guard pages" (which are really only "readonly pages in disguise").
Most modern processors support hardware breakpoints. Unless your program is to run on some very exotic platform, you can exploit these to have more fine-grained control in a similar way as by tampering with protections. See for example this article on another site, which describes how to do it under Windows on x86. This solution will require you to write a kind of "mini-debugger" and implies that you may possibly run into trouble when running your program under a real debugger.
I am using Intel's FORTRAN compiler to compile a numerical library. The test case provided errors out within libc.so.6. When I attach Intel's debugger (IDB) the application runs through successfully. How do I debug a bug where the debugger prevents the bug? Note that the same bug arose with gfortran.
I am working within OpenSUSE 11.2 x64.
The error is:
forrtl: severe (408): fort: (3): Subscript #1 of the array B has value -534829264 which is less than the lower bound of 1
The error message is pretty clear to me, you are attempting to access a non-existent element of an array. I suspect that the value -534829264 is either junk when you use an uninitialised variable to identify the element in the array, or the result of an integer arithmetic overflow. Either way you should switch on the compilation flag to force array bounds checking and run some tests. I think the flag for the Intel compiler would be -CB, but check the documentation.
As to why the program apparently runs successfully in the debugger I cannot help much, but perhaps the debugger imposes some default values on variables that the run time system itself doesn't. Or some other factor entirely is responsible.
EDIT:
Doesn't the run-time system tell you what line of code causes the problem ? Some more things to try to diagnose the problem. Use the compiler to warn you of
use of variables before they are initialised;
integer arithmetic overflow (not sure if the compiler can spot this ?);
any forced conversions from one type to another and from one kind to another within the same type.
Also, check that the default integer size is what you expect it to be and, more important, what the rest of the code expects it to be.
Not an expert in the area but couple of things to consider:
1) Is the debugger initialising the variable used as the index to zero first, but the non-debug does not and so the variable starts with a "junk" value (had an old version of Pascal that used to do that).
2) Are you using threading? If so is the debug changing the order of execution so some prep-thread is completing in time.